Страница 2 из 2

Re: Логические правила для изменения свойств задач

Добавлено: 06 май 2010, 07:15
de1
WaRoX, поясню:
Для чего вы хотите полного описания всех параметров?

В предыдущих постах я довольно подробно описал причины, по которым это описание необходимо. В двух словах (nothing personal, guys): уровень подготовки документации - это, как минимум, степень уважения и внимания к пользователю. Необходимо понимать, что я разделяю использование правил автоформатирования личной мной и другими пользователями. Теоретически я и сам могу разобраться, определить глубину использования этих самых правил (или неиспользования, что тоже не исключено). Как-то не совсем внимательно вы читаете то, что впоследствии комментируете, но повторюсь - вопрос я поднимаю, во-первых, больше с точки зрения среднестатистического пользователя, который при всем своем желании на данном этапе поучаствовать в обсуждении не сможет (см. предыдущие посты), во-вторых, исходя из личной заинтересованности, не зря же мы с вами этими прениями занимаемся. Мне, допустим, интересны, правила, которыми поделился edw, но в то же время я не хочу, чтобы этот "обмен" превратился в театр двух актеров, как-то не вяжется это с отличной идеей создания депозитария разного рода примеров.
а с введением автоформатирования все заговорили о необходимости документации... Не могу понять, почему.

Не все, только в этой ветке. А мне, в свою очередь, непонятно, как вам непонятно то, что понятно в среде любых разработчиков - услуга должна быть качественной. Я не знаю подоплеки (мало людей, работа по проекту MLO в свободное время, занятость по другим проектам) и, по большому счету, who cares? Я знаю лишь то, что качество feedback'а хромает, об этом не раз писали и пишут, и не только на этом форуме. Конечно, оффтоп, но это имеет непосредственное отношение к обсуждаемому вопросу.
P.S.
К слову: для задач, которые я хочу выполнить сегодня, я просто ставлю срок "сегодня", и постановка задачи в избранное не позволит мне выполнить эту задачу лучше, ведь сроки в таком случае жестко не фиксированы определенной датой.

Re: Логические правила для изменения свойств задач

Добавлено: 06 май 2010, 19:20
WaRoX
Ну вот это я и хотел узнать: говорите вы от своего лица или от среднестатистического пользователя. На мой взгяд, среднестатистическому пользователю будет как раз гораздо понятнее не просто описание всех-всех параметров (господи, кто этот список читать-то будет), а примеры их конкретного использования. Описало несколько человек примеров 20 использования, вот среднестатистический пользователь посмотрел, как они это сделали, и на этом примере повторил опыт, может, добавив что-то свое. Я не говорю, что документация нафиг никому не нужна, я имею в виду, что описание опыта применения, конкретных кейсов, сейчас в разы сейчас полезнее и приоритетнее, чем техническое описание параметров. Многие среднестатистические пользователи вообще тайм-менеджментом не увлекались, и слова автофокус, GTD, расстановка приоритетов для них вообще в новинку. А рассказывая конкретные примеры, можно заодно рассказать полезную теорию тайм-менеджмента. Вот помню, кто-то очень классно описывал, как в МЛО можно реализовать календарик-пинарик.

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

Re: Логические правила для изменения свойств задач

Добавлено: 13 май 2010, 06:41
edw
Кажется мы добрались до сути.
de1 писал(а):Пользователь заинтересован в первую очередь в личной эффективности использования возможностей программы.

Эту фразу можно читать по разному:
  • Пользователь заинтересован в первую очередь в личной эффективности
  • Пользователь заинтересован в первую очередь в эффективности использования возможностей программы
Так как в чём всё-таки интерес "среднестатистического пользователя"?
de1 писал(а):И далее, наигравшись вдоволь с разными, в нашем случае, операндами и определив для себя наиболее оптимальные, пользователь изъявляет желание поделиться со своими наиболее эффективными и удачными правилами с другими пользователями.

Мне кажется что это описание не соответствует модели поведения "среднестатистического пользователя".
Предполагаю, что количество проданных лицензий на русском на порядок(и) превышает число участников этого форума. Среднестатистический (в смысле статистики) пользователь предпочитает скачать софт, выбрать подходящий шаблон из числа входящих в поставку и вернуться к повседневным делам. Иногда, столкнувшись с определённым вопросом, он просматривает видеоуроки, читает справочную систему и этот форум. В случае если он не нашёл ответа на свой вопрос, среднестатистический пользователь регистрируется и задаёт вопросы на форуме. Среднестатистический пользователь НЕ играется с операндами и НЕ стремится поделиться своими наработками.
:!: Мне кажется, что описанная вами модель поведения больше соответствует "опытному пользователю" (опытный в смысле НЕ среднестатистический).
de1 писал(а):Для себя вынес в Excel все 40 операндов с возможными функциями, вывел отдельную графу "Efficiency Quotient", типа КПД, напротив каждого из операндов - одно из трех значений (Yes, No, Maybe), обозначающих возможность применения в моей системе, фильтрация по значению и - вуаля! определение промежуточного перечня моих подопытных операндов) За неимением лучшего, буду пока довольствоваться этим.

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

Вы публикуете вашу таблицу операндов и хотя бы один пример использования их в вашей системе. Возможно разработчики прокомментируют те из операндов, которые вы отметили как Yes. Ну или хотя бы те, в описании к которым вы допустили ошибку. Возможно другие пользователи переведут названия операндов на русский или подготовят описание функций тех операндов, которые вы ещё не описали. (Вы правы в том, что всё это должны были сделать разработчики ранее в документации). Но ведь не в этом ваша цель! Главное, что другие пользователи предложат свои варианты использования операндов, которые вы сможете использовать в качестве готовых шаблонов. Соответственно эти операнды будут задокументированы (дано описание функций) в первую очередь. Т.е. документация будет появляться не по мере добавления новых функций в МЛО, а по мере освоения этих функций пользователями для решения прикладных задач.

Re: Логические правила для изменения свойств задач

Добавлено: 13 май 2010, 10:51
de1
1. Имелась ввиду именно "личная эффективность использования возможностей программы среднестатистическим пользователем", в противопоставление общим интересам разработчика в отношении возможностей программы. Важен контекст - именно через призму примеров (учебных материалов). Т.е. разработчику важно огульно дать наиболее широкие рабочие возможности, ориентированные на всех пользователей, пользователь же заинтересован в том, чтобы взять максимум для своего личного использования.

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

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

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

В этом моменте не совсем согласен, про нелогичность я уже писал, получается телега впереди коня. Твердо убежден (и весь мой опыт подсказывает), что от того, как будет преподнесен материал, зависит степень его дальнейшей имплементации (на личном уровне каждый может в этом убедиться хотя бы на примере учебы). Как говорится, если профессор не может объяснить ребенку, чем он занимается — гоните его, он шарлатан (с). Ну аж если будут такие упущения в будущем, это приведет лишь к тому, что ряды потенциальных опытных пользователей будут пополняться крайне медленно, преимущественно из энтузиастов, дальше сами можете представить перспективы создания и постоянного пополнения депозитария примеров. Я уж не говорю о сужении фокуса применения, кого-то интересует опыт других в области коллективной работы, кому-то достаточно составления простейшего Grocery List, соответственно, единомышленников не только по технике применения MLO, но и по смежным сферам интереса найти будет сложнее. Надеюсь, что таким путем развития все не пойдет (хотя в настоящий момент именно так и движется).

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

Re: Логические правила для изменения свойств задач

Добавлено: 26 май 2010, 07:53
Sister
Ну вы тут наоффтопили... :shock:
По поводу самого предложения - я его поддерживаю. Иногда хочется иметь что-то типа триггеров, которые выполнялись бы в определенных ситуациях, меняя различные параметры задачи.

Re: Логические правила для изменения свойств задач

Добавлено: 27 май 2010, 02:57
edw
Sister, Спасибо за удачное название для этой функциональности. Согласен с тем, что эта тема перекликается с темой по парсингу. Дальнейшее обсуждение лучше вести там.