Сервис онлайн управления задачами, наш взгляд


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

    Похожие системы пишет под себя огромное количество разработчиков, даже прослеживаются некоторые тенденции:
    • большинство тяготеют к управлению проектами, т.е. уклон в область совместной работы, постановки задач другим пользователям и прочим видам collaboration
    • подходы к определенным вопросам очень сильно похожи на лидеров рынка (Google calendar с его принципами установки повторения задач, к примеру). Мало кто делает нормальное древовидное представление задач, т.к. коли это не особо распространено, то значит и не особо востребовано. Но я почему-то всегда попадаю в ту группу пользователей, которым не хватает возможности что-то подкрутить, порыться в настройках. Отдельная песня – идеология Apple, где в большинстве случаев настройки программы сводятся к паре галочек. Иногда такой подход даже обижает.


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

    Итак, в наличии было небольшое количество выделенных серверов в ДЦ Hetzner (Германия), арендованных по рабочим нуждам, но слабо используемых (основное назначение – хранение данных, поэтому нагрузки мало). Также имелся опыт разработки на T-SQL, Delphi, Visual C, .NET. Крайне мало опыта было в Javascript, пришлось наверстывать.

    Мы – это полтора разработчика и много подчиненных пользователей – тестеров. Система активно используется в повседневной работе, никак не связанной с разработкой софта. Специфика работы такова, что задач однотипных много, много из них еще не наступили, но нужно иметь возможность их видеть и делать заранее.

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

    Прежде всего некий disclaimer. Мы не пытались сделать очередной “комбайн”, наш сервис не является системой для, к примеру, багтрекинга, т.к. это абсолютно другая специфика. Сервис прежде всего ориентирован на обычных “продвинутых” пользователей, которым нужно чуть больше от систем управления задачами, область применения – учет личных задач (купить, отследить, напомнить и т.п.) с возможностью совместного использования с другими пользователями (пускай, родственники, коллеги).

    Что реализовать даже не пытались:
    • таймтрекинг
    • аналоги багтрекинга
    • общение, всякие социальные кнопки
    • строгого соответствия канонам GTD. Точнее все необходимое вроде для этого есть (поле «Контекст», тэги с неограниченной вложенностью), но особо на методику GTD не ориентировались.

    А нужно мне было от управления задачами следующее (список, конечно, неполный, но показательный):
    1. Cписок задач принципиально в древовидном виде, с папками и подпапками, вложенность должна быть неограничена (чтобы там ни говорили про то, что три уровня вложенности хватит всем – враки)
    2. добавление задач по электронной почте, причем при направлении по разным адресам — в разные подпапки
    3. учет домашних дел (оплата по квитанциям, проверка масла в машине, отслеживание сроков окончания оплаты и т.п. с разной степенью периодичности, автоповторения и настраивания уведомлений обо всем этом абсолютно разными способами — хотел чтобы об оплате я предупреждал сам себя три раза, а о некоторых событиях — предупреждал о просрочке более чем на неделю)
    4. по работе — тут сложность в количестве — нужно было отслеживать сроки окончания доверенностей, договоров, сертификатов и т.п., причем также нужно было настроить уведомления о пропуске сроков. Количество этих задач — сотни, поэтому ни один из существующих менеджеров задач с этим либо не справился, либо реализация всего этого была неудобной
    5. просмотр повестки дня (списка актуальных дел) кроме сегодняшнего еще и на любой произвольный период, причем с навороченной фильтрацией, к примеру в одном списке нужно было выводить текущие задачи, задачи которые начнутся в ближайшую неделю плюс все домашние задачи, кроме неважных задач (с небольшим приоритетом)
    6. давать доступ Read-only кому нужно на все это
    7. давать write доступ кому нужно, причем с правами изменения только определенных полей задачи (к примеру, работнику, который может только менять статус задачи)
    8. использование временных зон, т.к. коллеги работают с теми же данными, но в других часовых поясах, поэтому все используемые даты должны корректироваться в нужную временную зону
    9. система меток (тэгов) – обязательно древовидная, с возможностью совместного использования (т.е. чтобы определенные метки были видны другим пользователям, а другие – только мне)
    10. возможность временного сокрытия некоторых задач (к примеру – мозолит глаза какая-то задача – скрываем ее на 2 дня, после этого она опять появится). К слову такой механизм можно и так реализовать еще другими способами

    Ну и, понятно, что также нужны распространенные базовые функции:
    • вывод и отсылка на почту повестки дня (настраивается как простой вариант – просто список на почту ежедневно в назначенное время, так и в виде триггера по расписанию – высылаются нужные ветки задач путем редактирования текста письма)
    • настраиваемые пользовательские поля (настраиваемость, правда, заключается только в изменении названия, смена типа данных не реализована, пока не видел необходимости)
    • настраиваемый внешний вид задач (шрифт, иконка, цвета)
    • произвольная сортировка подзадач каждой задачи по трем критериям (задач, повторюсь, много, поэтому без сортировки никак)
    • RSS канал с настраиваемыми уведомлениями (ну люблю я лежа полистать feedly, заодно поглядеть и свою ленту уведомлений)
    • Поле «Прогресс» с графическим отображением (на самом деле, мало кому действительно нужно)
    • Приоритеты задач

    4 месяца работы и в итоге получился некий «движок» для учета задач, все что хотел — реализовал.

    Вкратце о получившемся.


    Основная единица информации – задача. Задача имеет дату начала и дату конца (due date). Если с due date все понятно, то с датой начала стоит объяснить, т.к. далеко не во всех аналогичных системах она есть. По сути, это дата, с которой задача считается актуальной. Т.е. присвоив задаче дату, она не будет выводиться в списке задач до тех пор, пока не наступит эта дата.

    В основе группировки задач и разделения доступа — понятие «Список задач». Т.е. некий набор задач, к примеру, «Дом», «Работа», «Компьютер» и пр. В других системах это может называться тасклистом, проектом, календарем, workspace и т.п. Также функция такого деления – каждый список имеет свои настройки прав доступа при совместном использовании и свои настройки временной зоны.

    Отдельно про временные зоны. Мне кажется, на практике это мало кому нужно, но нам это нужно было просто критически. Несколько наших работников и лиц, которым предоставлен доступ, работают в совершенно разных временных зонах, редактируя и просматривая задачи из одинаковых списков. Если при установке даты задачи указывать конкретно время особо и не нужно, то при настройке уведомлений, триггеров иногда необходимо указывать конкретное время, к примеру, ежедневно сменять статус задачи в 20-00. Т.е. смена статуса должна происходить именно в 20-00 временной зоны пользователя, поставившего триггер. Для корректной реализации этого устанавливается временная зона каждого пользователя и конкретного списка задач.

    Что касается прав доступа, то пришли к следующему решению. Пользователь может делегировать право на просмотр/редактирование определенного списка задач другому пользователю.

    Могут быть установлены следующие права:
    • Только просмотр
    • Только добавление задач
    • Только редактирование задач
    • Только удаление задач
    • Редактирование и удаление задач
    • Редактирование и добавление задач
    • Добавление и удаление задач
    • Полный доступ

    Дополнительно при условии права на редактирование устанавливается список полей, которые запрещено редактировать пользователю. Это позволяет реализовать такой механизм взаимодействия пользователей при совместной работе – кто-то, владеющий правами ставит задачи, а кто-то другой, имеющий только ограниченный набор прав может только помечать задачи как выполненные. Т.е. можно ставить задачи, не волнуясь, что кто-то сотрет саму задачу или что-то в ней подправит. Понятно, что в системах управления проектами все это реализовано на более высоком уровне, но мы не пытались объять необъятное и реализовали базовый набор.

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

    Фильтрация


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

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

    В дальнейшем оказалось, что пользы от фильтров гораздо больше – с их помощью можно определить набор повестки дня, рассылаемой пользователю ежедневно, плюс определить задачи, которые необходимо синхронизировать с google tasks. Но о google tasks лучше напишем отдельно.

    Мобильная версия.


    Сам я 80% процентов своего свободного времени провожу за iPad, поэтому вопрос создания приложения под iOS/Android не стоял – оно было необходимо. И было решено его не разрабатывать. Совсем. Пошли другим путем – путем гибкой синхронизации с Google Tasks можно основную часть повседневной работы (основное редактирование задач, просмотр и отметки о выполнении, т.е. основной функционал tasks) перенести именно в Google Tasks, а всю информацию периодически синхронизировать (двусторонним или односторонним путем) с сервисом. Точнее синхронизация автоматическая, точнее периодическая (push Google Tasks не поддерживает). Приложений для Google Tasks более чем достаточно, некоторые просто шедевры. Почему бы хотя бы в этой части не изобретать велосипед, а использовать чужие наработки :)

    Техническая сторона.


    Сервис написан на ASP.NET, крутится на одном дедике. БД – PostgreSQL, крутится на другом.
    Изначально писалось на MSSQL, но потом стало понятно, что постгрес подходит больше. Тяжеловато было переписывать все на постгрес, но оно того стоило.
    80% бизнес-логики реализованы в БД, так оно как-то быстрее работает.
    Использованы серверные компоненты DevExpress – основная нагрузка лежит на ASPxTreeList. Да, пришлось использовать именно серверные компоненты, пускай это лишний трафик для клиента, но иначе не реализовать работу с тысячами задач и некоторыми функциями. Да, это ведет к некой инертности работы “дерева”, но “отклик” порядка 200-300 мс практически незаметен, поэтому устроил. Из аналогичных компонентов пробовал и телериковские, но там очень неприятные тормоза при сворачивании/разворачивании дерева, некомфортно работать.
    Используется ASP.NET WebForms, знаю, что немного устаревшая технология, но практически вся работа сосредоточена на одной странице и постоянных коллбэках одного элемента, поэтому переход на MVC мало что бы дал. А вечную проблему излишнего размера ViewState вроде минимизировал.
    В два отдельных приложения вынесены операции с почтой (прием задач по почте и отправка) и синхронизация с Google Tasks. Их писал на Delphi.

    Опять disclaimer


    1. Ради убыстрения разработки многие относительно нечасто используемые части интерфейса (редактирование списков задач, триггеров) написаны с применением готовых элементов управления от DevExpress, поэтому чуть тяжеловаты
    2. Поддерживаются все распространенные браузеры, но со старыми версиями могут быть проблемы. IE8 иногда выдает ошибки, но т.к. под рукой чистого IE8 нет, руки пока до исправления ошибок не дошли.
    3. Синхронизация с Google Tasks работает, но злобный Google недостаточно пока увеличил квоту на запросы к их API, поэтому теоретически в случае притока пользователей, которые настроят эту фичу, возможна остановка синхронизации в ночное время на первых порах. Долблю их саппорт как могу.

    Монетизация и сохранность данных


    Монетизация в обозримом будущем, разумеется, не планируется. Если она и будет, то только в случае постоянного роста активных пользователей и увеличения потребности в мощностях. На данный момент ресурсов у нас достаточно, чтобы без напряга выделить пару серверов под этот проект, тем более по hetzner`овским ценам. В случае чего — можно и увеличить количество. Если какие-либо платные аккаунты будут вводиться, то правильной практикой будет то, что зарегистрировавшиеся ранее пользователи получат пожизненный бесплатный «premium» аккаунт. Про сохранность данных — в случае закрытия сервиса все пользователи будут уведомлены и будет не менее двух месяцев на перенос данных. Если кто-то знает как лучше предложить пользователям резервировать данные — сообщите, пожалуйста. Мне пока кроме синхронизации в Google Tasks ничего на ум не приходит. Можно и экспорт прикрутить, к примеру, в csv.

    Планы


    • Интеграция с google calendar. В процессе. Пока нет четкого понимания в каком виде это красиво реализовать, т.к. аналогов нет.
    • Оптимизация, оптимизация, оптимизация. Особенно использования клиентского трафика. Плюс под старые браузеры.
    • SSL
    • Добавить временных вариантов повторения и планирования задач (пока реализованы базовые периодичности)
    • Кинулся было писать календарное представление задач, написал, но потом решил сосредоточиться на стандартном древовидном, т.к. не стоит сразу за все хвататься, не сделав безглючным уже реализованное.

    Ну и чуть позже опубликую пост поподробнее про триггеры и синхронизацию с Google Tasks, там есть что рассказать.
    Ссылка на сам сервис — betasked.ru
    UPD По-моему много кто испугался первого скрина, но ничто не мешает убрать ненужные поля, выбрать тему оформления и работать так:

    или так:
    image
    betasked.ru
    16,99
    Компания
    Поделиться публикацией

    Комментарии 46

      +21
      Возможно сервис и хороший, но интерфейс у вас капец какой страшный. Видно что к нему не касалась рука ни проектировщика интерфейсов, ни дизайнера.
        +1
        Молча соглашусь. Среди нас нет ни проектировщиков, ни дизайнеров. Все время уходило на функционал, а для приемлемости дизайна куплены devexpress`овые компоненты.
          –2
          bootstrap под силу прикрутить любому программисту. На входе получите интерфейс который выглядит вполне себе опрятно.
            +3
            Это тут совершенно не при чем. То как это будет выглядеть не сделает интерфейс удобным и понятным. Тут нужно заморочиться с-месяц сначала дизайнеру интерфейсов чтобы спроектировать всё правильно, а потом уже можно бутстрап вешать или дизайнера привлекать.
            0
            О, то-то видны знакомые элементы интерфейса. Если у вас не самая старая версия DevExpress, то можно выставить темки Metropolis, Metropolis Blue. Они смотрятся симпатичнее.
              +1
              Так версия последняя, саму тему оформления (не только Метрополис) пользователь может выбрать в два клика, ткнув Settings-Theme. Я думаю, если бы скрин приложил в этой теме, то про дизайн претензий было бы чуть меньше. Хотя как раз для реальной работы она менее удобна — бордеров мало и прочий минимализм.
          +2
          Лучший интерфейс задачника — это когда вы открываете его и последовательно выполняете действия, которые он вам предлагает. Лазание по иерархиям, получение несвязных уведомлений — зло, имхо. Однако, вы неплохо разобрались с TreeView.
            +1
            В том то и дело, что иерархия просто необходима, когда задач очень много. 10-20 задач еще можно в одном списке видеть, но когда их за сотни (к примеру, однотипных, но которые учитывать нужно именно отдельно), то тогда без дерева не обойтись.
              0
              Иерархия обязательна.

              Лично мне иерархия помогает для борьбы с прокрастинацией:
              Есть большая сложная задача, я разбиваю ее на три-десять подзадач и начинаю делать одну из них.
                0
                Вы не поняли фишку. Человек в одно время может выполнять только одну задачу. Только ее (и может быть следующую) он и должен видеть. Все остальное на текущий момент — мусор. То, что у вас — это такой же мусор на столе из бумажек и стикеров. Это, конечно, позволяет не забыть про некие события, но никак не оптимизирует работу. Такую задачу можно решить с помощью банального Excel.

                Может я, конечно, чего не понял или до конца не разобрался в вашей программе… возможно, как административный интерфейс для создания задач это вполне приемлемо.
                  +1
                  Тот вал информации, который Вы увидели на скринах — это, по сути и есть этот мусор в виде абсолютно всех задач. Чтобы сосредоточиться на конкретных областях — есть фильтры, к примеру «Список покупок», «Задачи, истекающие сегодня», «Задачи, истекающие в следующем месяце», которые пользователь сам и настраивает. Там выводится только нужная информация.
                  Аналогичный подход, кстати в программе MyLifeOrganized, там также в виде дерева вводится весь массив текущих задач, а потом нужные задачи фильтрами и в соответствии с настраиваемыми «весами» выводятся уже в виде списка.
                    0
                    Я когда-то, как и вы, работал над трекингом задач в относительно большой компании. Трекер так же был иерархическим, похожим на ваш, он работал, но возникал ряд проблем.
                    Самая важная — по какому принципу строить иерархию? Например задачи можно объединить по проекту, а можно по исполнителям. Внутри проекта, например, по релизам, или по модулям, и т.д. Принципов группировки может быть очень много, и определённый момент определённому человеку нужен только один, а другие бесполезны. Так что фактически ваша иерархия никому не нужна, а показывать нужно ту структуру, которая нужна в данный момент. Мы называли это досками, у каждой доски был свой пользователь и своя структура. Например «Мои текущие задания» — это очередь входящих заданий в порядке приоритета выполнения + список задач в работе.
                    Ещё вы не затронули тему планирование выполнения задач. При высокой нагруженности людей сложно предсказать, когда какая задача будет сделана, а для планирования деятельности это очень важно. Если вас это ещё ждёт впереди, то сделаю подсказку: имея ваши инструменты скорее всего возникнет желание для каждой задачи назначить время выполнения, а это путь в никуда.
                  0
                  Достаточно двух уровней.

                  1. проект/большая задача
                  2. задача/маленькая задача

                  Остальное от лукавого и будет больше времени уходить на посмотреть это все.

                  PS Посмотрите к примеру teambox. Я использую правда не их 4 версию, а 3 версию. Там как раз так.
                    0
                    Ну вот смотрите, как можно таким уровнем вложенности жить?
                    Есть задача поднять конверсии в проекте, там сразу 3 подзадачи на эксперимент с тремя вариантами как это сделать, в каждой их них есть работа художника программиста геймдиза. И там ещё подуровни могут расти. Ну и зачем уплощать это? На исполнение оно идёт плоским списком, но суть то у неё именно такая, иерархическая.
                      0
                      Затем что у человека вполне конечное количество обозреваемой информации.
                      +1
                      Teambox смотрели. Там иерархии нет вообще, точнее жесткая структура «проект — список — задача». Это, наверное, большинству подойдет, но нам не подходило. Попытались реализовать свое видение — первоначальное деление по спискам (на уровне списков настраиваются права доступа, некоторые триггеры, синхронизация), далее — простая иерархическая структура папок/задач.
                      И не стоит так категорично утверждать про два-три уровня. Как только задач больше сотни — иерархия необходима, это мое мнение. Да, частично можно обойтись без нее путем фильтров, тэгов и пр, но не всегда.
                        0
                        Как только задач больше сотни — иерархия необходима, это мое мнение.

                        То стоит сразу подумать что что-то не так в консерватории и может имеет смысл побить как раз на проект — список — задача. Да кстати в тимбоксе есть еще один уровень организация.
                          +1
                          Ну не всегда подходят искусственно притягиваемые понятия вроде «проект».
                          Чтобы не быть голословным, обратимся к практике. Пускай одна (именно одна из) из областей, которые нужно отслеживать — домены/сертификаты/кредитные карты и т.п. Пускай домены. Пускай задача выглядит как «Продлить домен google.com». Доменов к примеру две сотни (это пример, я к SEO отношения не имею). Один из важных параметров, который нужно принимать во внимание — регистратор. Т.е. есть необходимость вывести список задач продления доменов именно по опредленному регистратору. Мы, к примеру, вместо доменов учитываем сертификаты в разрезе удостоверяющих центров, но не в этом дело. Для фильтрации именно по определенному регистратору нужно как-то эти задачи обособить (чтобы был какой-то критерий для фильтрации). Вариантов немало, но все они имеют недостатки по сравнению с иерархией.
                          Т.е. можно включать название регистратора в текст самой задачи. Костыль. Дай бог каждый раз написать правильно. Если данные вводит другой человек — также отслеживать чтобы вводили правильно.
                          Можно обособить эти задачи с помощью тэгов. Но тогда нам нужно городить кучу тэгов, которые в других задачах и не нужны и которые будут мозолить глаза. Делать иерархию тэгов — тоже скажете, что излишнее усложнение. И также нужно не забывать проставлять эти тэги.
                          Делать на регистраторов отдельные списки/проекты — тоже не решение. Когда их немного, можно и потерпеть, а когда много — проблема.
                          А вот с помощью иерархии делаем структуру типа Домены/GoDaddy/example.com.
                          И далее фильтрацией по папке получаем только задачи по продлению у регистратора GoDaddy.com. Это только один из примеров, которые продиктованы нам жизнью. Спросите, зачем нам такие запросы — к примеру, фильтрацией по удостоверяющему центру определяем список заканчивающихся сертификатов и предпринимаем меры (авансируем оплату разом).
                          Да, возможно большинству такие сложности не нужны, поэтому и не нашлось сервисов, грамотно реализующих учет таких задач. И поэтому пришлось городить весь этот огород.
                            0
                            Эм никакой разницы делать тегами или деревом нет. И часто сделать тегами лучше, так-как фильтровать по ним немного проще. Опять же вами приведенная задача это в чистом виде «натягивание совы на глобус». Решение задачи неподходящими средствами.
                        +1
                        Достаточно двух уровней.

                        Не всем и не всегда.
                        Мне например не хватает.
                        Список проектов-задач-подзадач у меня весьма ветвистый.

                        Когда планирую/разбиваю на подзадачи итд — я смотрю представление с большим и страшным деревом.
                        Когда смотрю какую задачу взять — смотрю в плоский список с фильтрами и сортировками.

                        ПС: Сейчас в тудушнике 167 задач в 11 проектах
                          0
                          Как только у вас не два уровня, начинаются пляски с фильтрами. В итоге приходим в итоге все равно к двум уровням.
                            0
                            Ну может быть.
                            Но мне очень удобно работать с деревом, уровни в котором ограничиваются только моей фантазией, а не фантазией разработчика.
                            Щелкнул в одну вкладку — вот он, полный обзор, что от чего зависит, что из чего состоит итд.
                            Поставил метки, щелкнул в другую вкладку — вот он плоский список, отмеченные задачи вверху списка и ничего не отвлекает.
                              0
                              Но мне очень удобно работать с деревом, уровни в котором ограничиваются только моей фантазией, а не фантазией разработчика.

                              Давайте я задам вам простой вопрос. Какова типичная вложенность дерева? :) Я думаю весьма редко больше трех вместе с терминальными листьями.

                              Щелкнул в одну вкладку — вот он, полный обзор, что от чего зависит, что из чего состоит итд.

                              Я сильно сомневаюсь, что вы полностью разворачиваете дерево.

                              Поставил метки, щелкнул в другую вкладку — вот он плоский список, отмеченные задачи вверху списка и ничего не отвлекает.

                              Это и есть фильтры. В этом плане весьма интересен Mylyn. Особенно учитывая возможность фокусировки на задачах и передача контекста (открытые файлы в проекте, важные для этого тикета файлы т.п.)
                                +1
                                Какова типичная вложенность дерева?

                                Типично 3 — 5 уровней. В редких случаях бывает больше.

                                Я сильно сомневаюсь, что вы полностью разворачиваете дерево.

                                Не чаще раза в месяц, но таки разворачиваю.

                                Это и есть фильтры

                                Дык я с этим не спорю.

                                Я спорю вот с этим
                                Достаточно двух уровней

                                  0
                                  Не чаще раза в месяц, но таки разворачиваю.

                                  Фактически это говорит о том что 3-5 уровней все же не сильно необходимы :)

                                  Дык я с этим не спорю.

                                  Я спорю вот с этим

                                  При фильтрах вложенность у вас будет два или один. Фактически все что выше это селекторы. Их можно к примеру тегами обеспечивать.
                                    +1
                                    Не чаще раза в месяц я разворачиваю ВСЕ дерево.
                                    Отдельные ветки разворачиваю ежедневно.
                                    Вложенность позволяет структурировать задачи оптимальным для меня способом.

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

                                    Начинал пользоваться прекрасными во всех отношениях инструментами, которые практически идеально мне подходили.
                                    И расставался с ними, из-за таких вот ограничений. Глубина только такая — и все, структурировать тэгами или пользовательскими полями и все.

                                    В результате так и пользуюсь AbstractSpoon ToDoList, который хоть и не вершина удобства — но хотя бы не ограничивает меня.
                                      0
                                      что-то мне подсказывает, что вы просто «захардкодили» в структуру все свои «фильтры». Само по себе древовидное представление может быть и обеспечивает большую гибкость, но после того, как структура была создана — она ее теряет. Фактически, система заточена под руководителя. А конечный исполнитель вынужден приспосабливаться. Хозяин — барин, как говорится.
                                        0
                                        «захардкодили» в структуру все свои «фильтры»

                                        Кхм, не понял что и куда я захардкодил.

                                        Есть большое, страшное дерево

                                        Верхние узлы = Проекты
                                        Этот уровень меняется довольно редко
                                        Проекты бьются на Задачи или Задачки
                                        Задачи бъются на Задачки
                                        Задачки могут оказаться крупноватыми и либо перенесутся уровнем выше, либо разобьются на Задачечки.
                                        У всех элементов есть Приоритет и Тэги

                                        Дерево дает наглядный обзор:
                                        Где что и в каком количестве ждет решения.
                                        Что из чего состоит.
                                        Что от чего зависит.

                                        Для обзора и планирования — смотрю и правлю дерево.
                                        Для выполнения — смотрю в плоский список с сортировкой по Приоритету и Тэгам.

                                        Можно убрать (или ограничить до двух уровней) дерево — которое по неизвестной причине вызывает идиосинкразию.

                                        Но тогда придется усиленно плодить тэги, и фильтровать по ним.
                                        Соответственно наглядность сильно ухудшится.
                                          0
                                          Естесственно, если весь список задач состоит из текучки или кол-во проектов невелико — то особой глубины вложенности и не надо.
                                          0
                                          Насчет «система заточена под руководителя»
                                          Я эту систему и никому не навязываю, использую для себя.
                                          В данный момент у меня остался всего один сотрудник в «группе», он планирует дела так — как ему удобно.
                                          Я со своей стороны вешаю Тэг «Контроль», на задачи которые отдаю ему, и скажем Тэг «План-Неделя» для своих задач.

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

                                          На самом деле тут можно спорить долго.
                                          У всех своя жизнь, свои принципы и свои инструменты.
                                          Но обсуждать и делиться своим опытом — таки полезно :)
                                            0
                                            я собственно просто обсуждаю недостатки абстрактного дерева задач :)

                                            Так вот, например, дерево группирует задачи по Проект/Регистратор/Домен. А бухгалтеру было бы удобнее видеть Регистратор/Дата (месяц) продления/Домен. И он как-бы пролетает мимо дерева, потому что структура рассчитана на другое.

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

                                            Лучше иметь плоский список, но продвинутую систему фильтров/группировок, через которые и формировать представление адекватное решаемой задаче.
                        0
                        Лучший интерфейс задачника — бумага! Он самый гибкий в плане настроек.
                          0
                          В некотором смысле вы правы, при этом у бумаги есть фундаментальные ограничения на поиск, разделение доступа и напоминания :-)
                          –1
                          Эта задача становиться… :(
                            +1
                            Немного не понял комментария, это Вы про орфографию? Так фраза звучит «Эта задача будет заново становиться», все правильно.
                              +1
                              Перечитал, но когда уже написал комментарий и самому стало стыдно. Готов к расправе.
                            0
                            У нас реализован именно такой подход. Мы также считаем, что иерархии в некоторых случаях — лишние. см habrahabr.ru/company/prettytasks/blog/201084/
                            +4
                            Напомнило картинку: «Программист! Даешь понятный интерфейс!»
                              0
                              Представляю сколько это человекочасов и мозгодней. Вы молодцы. И, уверен, найдёте свою аудиторию среди тех, кто не боится разбираться.
                                –3
                                Стыдно такой интерфейс выкладывать на всеобщее обозрение. Больше говорит о халатном подходе, чем о чём-либо другом. Правда, не обижайтесь. Но это все равно, что ресторан, где подают в грязной посуде. Я бы убрал в черновики и срочно нанял дизайнера.
                                  +1
                                  Столько комментариев про непонятный интерфейс и ни одной ссылки на пример понятного. Вот как должен выглядить понятный интерфейс — habrahabr.ru/post/144489/
                                    0
                                    А зачем задачи организовывать в деревья?
                                      +3
                                      Ну если вкратце — то иерархия нужна тогда, когда задач уже много. Также как и в случае с файловой системой — структура папки/подпапки удобна же. Так и в случае с большим количеством задач — объединение их в папки убирает их с глаз.
                                      0
                                      Хорошая попытка!
                                      Автору респект и уважуха за то, что не поленились и довели до более-менее промышленного состояния.

                                      При этом, хочу заметить что сейчас достаточно много готовых онлайн — сервисов. Из того, что наиболее похоже на ваш — mylifeorganized.net — дает замечательную иерархию + офлайн-синхронизацию.
                                      Papirus.net — вложенность задач и разделение доступа.

                                      Возможно там найдете вдохновение для модернизации своего интерфейса( а это важно для действительно массового продукта).

                                      Удачи!
                                        0
                                        а можно новый корень меток как-нибудь создавать? А то у меня только вложенные
                                          0
                                          а вижу. нужно быструю метку добавить и она сохранится в корне. А в списке этого сделать нельзя почему-то.

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

                                        Самое читаемое