Комментарии 47
Возможно сервис и хороший, но интерфейс у вас капец какой страшный. Видно что к нему не касалась рука ни проектировщика интерфейсов, ни дизайнера.
Молча соглашусь. Среди нас нет ни проектировщиков, ни дизайнеров. Все время уходило на функционал, а для приемлемости дизайна куплены devexpress`овые компоненты.
bootstrap под силу прикрутить любому программисту. На входе получите интерфейс который выглядит вполне себе опрятно.
О, то-то видны знакомые элементы интерфейса. Если у вас не самая старая версия DevExpress, то можно выставить темки Metropolis, Metropolis Blue. Они смотрятся симпатичнее.
Так версия последняя, саму тему оформления (не только Метрополис) пользователь может выбрать в два клика, ткнув Settings-Theme. Я думаю, если бы скрин приложил в этой теме, то про дизайн претензий было бы чуть меньше. Хотя как раз для реальной работы она менее удобна — бордеров мало и прочий минимализм.
Лучший интерфейс задачника — это когда вы открываете его и последовательно выполняете действия, которые он вам предлагает. Лазание по иерархиям, получение несвязных уведомлений — зло, имхо. Однако, вы неплохо разобрались с TreeView.
В том то и дело, что иерархия просто необходима, когда задач очень много. 10-20 задач еще можно в одном списке видеть, но когда их за сотни (к примеру, однотипных, но которые учитывать нужно именно отдельно), то тогда без дерева не обойтись.
Иерархия обязательна.
Лично мне иерархия помогает для борьбы с прокрастинацией:
Есть большая сложная задача, я разбиваю ее на три-десять подзадач и начинаю делать одну из них.
Лично мне иерархия помогает для борьбы с прокрастинацией:
Есть большая сложная задача, я разбиваю ее на три-десять подзадач и начинаю делать одну из них.
Вы не поняли фишку. Человек в одно время может выполнять только одну задачу. Только ее (и может быть следующую) он и должен видеть. Все остальное на текущий момент — мусор. То, что у вас — это такой же мусор на столе из бумажек и стикеров. Это, конечно, позволяет не забыть про некие события, но никак не оптимизирует работу. Такую задачу можно решить с помощью банального Excel.
Может я, конечно, чего не понял или до конца не разобрался в вашей программе… возможно, как административный интерфейс для создания задач это вполне приемлемо.
Может я, конечно, чего не понял или до конца не разобрался в вашей программе… возможно, как административный интерфейс для создания задач это вполне приемлемо.
Тот вал информации, который Вы увидели на скринах — это, по сути и есть этот мусор в виде абсолютно всех задач. Чтобы сосредоточиться на конкретных областях — есть фильтры, к примеру «Список покупок», «Задачи, истекающие сегодня», «Задачи, истекающие в следующем месяце», которые пользователь сам и настраивает. Там выводится только нужная информация.
Аналогичный подход, кстати в программе MyLifeOrganized, там также в виде дерева вводится весь массив текущих задач, а потом нужные задачи фильтрами и в соответствии с настраиваемыми «весами» выводятся уже в виде списка.
Аналогичный подход, кстати в программе MyLifeOrganized, там также в виде дерева вводится весь массив текущих задач, а потом нужные задачи фильтрами и в соответствии с настраиваемыми «весами» выводятся уже в виде списка.
Я когда-то, как и вы, работал над трекингом задач в относительно большой компании. Трекер так же был иерархическим, похожим на ваш, он работал, но возникал ряд проблем.
Самая важная — по какому принципу строить иерархию? Например задачи можно объединить по проекту, а можно по исполнителям. Внутри проекта, например, по релизам, или по модулям, и т.д. Принципов группировки может быть очень много, и определённый момент определённому человеку нужен только один, а другие бесполезны. Так что фактически ваша иерархия никому не нужна, а показывать нужно ту структуру, которая нужна в данный момент. Мы называли это досками, у каждой доски был свой пользователь и своя структура. Например «Мои текущие задания» — это очередь входящих заданий в порядке приоритета выполнения + список задач в работе.
Ещё вы не затронули тему планирование выполнения задач. При высокой нагруженности людей сложно предсказать, когда какая задача будет сделана, а для планирования деятельности это очень важно. Если вас это ещё ждёт впереди, то сделаю подсказку: имея ваши инструменты скорее всего возникнет желание для каждой задачи назначить время выполнения, а это путь в никуда.
Самая важная — по какому принципу строить иерархию? Например задачи можно объединить по проекту, а можно по исполнителям. Внутри проекта, например, по релизам, или по модулям, и т.д. Принципов группировки может быть очень много, и определённый момент определённому человеку нужен только один, а другие бесполезны. Так что фактически ваша иерархия никому не нужна, а показывать нужно ту структуру, которая нужна в данный момент. Мы называли это досками, у каждой доски был свой пользователь и своя структура. Например «Мои текущие задания» — это очередь входящих заданий в порядке приоритета выполнения + список задач в работе.
Ещё вы не затронули тему планирование выполнения задач. При высокой нагруженности людей сложно предсказать, когда какая задача будет сделана, а для планирования деятельности это очень важно. Если вас это ещё ждёт впереди, то сделаю подсказку: имея ваши инструменты скорее всего возникнет желание для каждой задачи назначить время выполнения, а это путь в никуда.
Достаточно двух уровней.
1. проект/большая задача
2. задача/маленькая задача
Остальное от лукавого и будет больше времени уходить на посмотреть это все.
PS Посмотрите к примеру teambox. Я использую правда не их 4 версию, а 3 версию. Там как раз так.
1. проект/большая задача
2. задача/маленькая задача
Остальное от лукавого и будет больше времени уходить на посмотреть это все.
PS Посмотрите к примеру teambox. Я использую правда не их 4 версию, а 3 версию. Там как раз так.
Ну вот смотрите, как можно таким уровнем вложенности жить?
Есть задача поднять конверсии в проекте, там сразу 3 подзадачи на эксперимент с тремя вариантами как это сделать, в каждой их них есть работа художника программиста геймдиза. И там ещё подуровни могут расти. Ну и зачем уплощать это? На исполнение оно идёт плоским списком, но суть то у неё именно такая, иерархическая.
Есть задача поднять конверсии в проекте, там сразу 3 подзадачи на эксперимент с тремя вариантами как это сделать, в каждой их них есть работа художника программиста геймдиза. И там ещё подуровни могут расти. Ну и зачем уплощать это? На исполнение оно идёт плоским списком, но суть то у неё именно такая, иерархическая.
Teambox смотрели. Там иерархии нет вообще, точнее жесткая структура «проект — список — задача». Это, наверное, большинству подойдет, но нам не подходило. Попытались реализовать свое видение — первоначальное деление по спискам (на уровне списков настраиваются права доступа, некоторые триггеры, синхронизация), далее — простая иерархическая структура папок/задач.
И не стоит так категорично утверждать про два-три уровня. Как только задач больше сотни — иерархия необходима, это мое мнение. Да, частично можно обойтись без нее путем фильтров, тэгов и пр, но не всегда.
И не стоит так категорично утверждать про два-три уровня. Как только задач больше сотни — иерархия необходима, это мое мнение. Да, частично можно обойтись без нее путем фильтров, тэгов и пр, но не всегда.
Как только задач больше сотни — иерархия необходима, это мое мнение.
То стоит сразу подумать что что-то не так в консерватории и может имеет смысл побить как раз на проект — список — задача. Да кстати в тимбоксе есть еще один уровень организация.
Ну не всегда подходят искусственно притягиваемые понятия вроде «проект».
Чтобы не быть голословным, обратимся к практике. Пускай одна (именно одна из) из областей, которые нужно отслеживать — домены/сертификаты/кредитные карты и т.п. Пускай домены. Пускай задача выглядит как «Продлить домен google.com». Доменов к примеру две сотни (это пример, я к SEO отношения не имею). Один из важных параметров, который нужно принимать во внимание — регистратор. Т.е. есть необходимость вывести список задач продления доменов именно по опредленному регистратору. Мы, к примеру, вместо доменов учитываем сертификаты в разрезе удостоверяющих центров, но не в этом дело. Для фильтрации именно по определенному регистратору нужно как-то эти задачи обособить (чтобы был какой-то критерий для фильтрации). Вариантов немало, но все они имеют недостатки по сравнению с иерархией.
Т.е. можно включать название регистратора в текст самой задачи. Костыль. Дай бог каждый раз написать правильно. Если данные вводит другой человек — также отслеживать чтобы вводили правильно.
Можно обособить эти задачи с помощью тэгов. Но тогда нам нужно городить кучу тэгов, которые в других задачах и не нужны и которые будут мозолить глаза. Делать иерархию тэгов — тоже скажете, что излишнее усложнение. И также нужно не забывать проставлять эти тэги.
Делать на регистраторов отдельные списки/проекты — тоже не решение. Когда их немного, можно и потерпеть, а когда много — проблема.
А вот с помощью иерархии делаем структуру типа Домены/GoDaddy/example.com.
И далее фильтрацией по папке получаем только задачи по продлению у регистратора GoDaddy.com. Это только один из примеров, которые продиктованы нам жизнью. Спросите, зачем нам такие запросы — к примеру, фильтрацией по удостоверяющему центру определяем список заканчивающихся сертификатов и предпринимаем меры (авансируем оплату разом).
Да, возможно большинству такие сложности не нужны, поэтому и не нашлось сервисов, грамотно реализующих учет таких задач. И поэтому пришлось городить весь этот огород.
Чтобы не быть голословным, обратимся к практике. Пускай одна (именно одна из) из областей, которые нужно отслеживать — домены/сертификаты/кредитные карты и т.п. Пускай домены. Пускай задача выглядит как «Продлить домен google.com». Доменов к примеру две сотни (это пример, я к SEO отношения не имею). Один из важных параметров, который нужно принимать во внимание — регистратор. Т.е. есть необходимость вывести список задач продления доменов именно по опредленному регистратору. Мы, к примеру, вместо доменов учитываем сертификаты в разрезе удостоверяющих центров, но не в этом дело. Для фильтрации именно по определенному регистратору нужно как-то эти задачи обособить (чтобы был какой-то критерий для фильтрации). Вариантов немало, но все они имеют недостатки по сравнению с иерархией.
Т.е. можно включать название регистратора в текст самой задачи. Костыль. Дай бог каждый раз написать правильно. Если данные вводит другой человек — также отслеживать чтобы вводили правильно.
Можно обособить эти задачи с помощью тэгов. Но тогда нам нужно городить кучу тэгов, которые в других задачах и не нужны и которые будут мозолить глаза. Делать иерархию тэгов — тоже скажете, что излишнее усложнение. И также нужно не забывать проставлять эти тэги.
Делать на регистраторов отдельные списки/проекты — тоже не решение. Когда их немного, можно и потерпеть, а когда много — проблема.
А вот с помощью иерархии делаем структуру типа Домены/GoDaddy/example.com.
И далее фильтрацией по папке получаем только задачи по продлению у регистратора GoDaddy.com. Это только один из примеров, которые продиктованы нам жизнью. Спросите, зачем нам такие запросы — к примеру, фильтрацией по удостоверяющему центру определяем список заканчивающихся сертификатов и предпринимаем меры (авансируем оплату разом).
Да, возможно большинству такие сложности не нужны, поэтому и не нашлось сервисов, грамотно реализующих учет таких задач. И поэтому пришлось городить весь этот огород.
Достаточно двух уровней.
Не всем и не всегда.
Мне например не хватает.
Список проектов-задач-подзадач у меня весьма ветвистый.
Когда планирую/разбиваю на подзадачи итд — я смотрю представление с большим и страшным деревом.
Когда смотрю какую задачу взять — смотрю в плоский список с фильтрами и сортировками.
ПС: Сейчас в тудушнике 167 задач в 11 проектах
Как только у вас не два уровня, начинаются пляски с фильтрами. В итоге приходим в итоге все равно к двум уровням.
Ну может быть.
Но мне очень удобно работать с деревом, уровни в котором ограничиваются только моей фантазией, а не фантазией разработчика.
Щелкнул в одну вкладку — вот он, полный обзор, что от чего зависит, что из чего состоит итд.
Поставил метки, щелкнул в другую вкладку — вот он плоский список, отмеченные задачи вверху списка и ничего не отвлекает.
Но мне очень удобно работать с деревом, уровни в котором ограничиваются только моей фантазией, а не фантазией разработчика.
Щелкнул в одну вкладку — вот он, полный обзор, что от чего зависит, что из чего состоит итд.
Поставил метки, щелкнул в другую вкладку — вот он плоский список, отмеченные задачи вверху списка и ничего не отвлекает.
Но мне очень удобно работать с деревом, уровни в котором ограничиваются только моей фантазией, а не фантазией разработчика.
Давайте я задам вам простой вопрос. Какова типичная вложенность дерева? :) Я думаю весьма редко больше трех вместе с терминальными листьями.
Щелкнул в одну вкладку — вот он, полный обзор, что от чего зависит, что из чего состоит итд.
Я сильно сомневаюсь, что вы полностью разворачиваете дерево.
Поставил метки, щелкнул в другую вкладку — вот он плоский список, отмеченные задачи вверху списка и ничего не отвлекает.
Это и есть фильтры. В этом плане весьма интересен Mylyn. Особенно учитывая возможность фокусировки на задачах и передача контекста (открытые файлы в проекте, важные для этого тикета файлы т.п.)
Какова типичная вложенность дерева?
Типично 3 — 5 уровней. В редких случаях бывает больше.
Я сильно сомневаюсь, что вы полностью разворачиваете дерево.
Не чаще раза в месяц, но таки разворачиваю.
Это и есть фильтры
Дык я с этим не спорю.
Я спорю вот с этим
Достаточно двух уровней
Не чаще раза в месяц, но таки разворачиваю.
Фактически это говорит о том что 3-5 уровней все же не сильно необходимы :)
Дык я с этим не спорю.
Я спорю вот с этим
При фильтрах вложенность у вас будет два или один. Фактически все что выше это селекторы. Их можно к примеру тегами обеспечивать.
Не чаще раза в месяц я разворачиваю ВСЕ дерево.
Отдельные ветки разворачиваю ежедневно.
Вложенность позволяет структурировать задачи оптимальным для меня способом.
Можно структурировать тэгами, или писать нечто объединяющее задачи прямо в их названии.
Но зачем?
Начинал пользоваться прекрасными во всех отношениях инструментами, которые практически идеально мне подходили.
И расставался с ними, из-за таких вот ограничений. Глубина только такая — и все, структурировать тэгами или пользовательскими полями и все.
В результате так и пользуюсь AbstractSpoon ToDoList, который хоть и не вершина удобства — но хотя бы не ограничивает меня.
Отдельные ветки разворачиваю ежедневно.
Вложенность позволяет структурировать задачи оптимальным для меня способом.
Можно структурировать тэгами, или писать нечто объединяющее задачи прямо в их названии.
Но зачем?
Начинал пользоваться прекрасными во всех отношениях инструментами, которые практически идеально мне подходили.
И расставался с ними, из-за таких вот ограничений. Глубина только такая — и все, структурировать тэгами или пользовательскими полями и все.
В результате так и пользуюсь AbstractSpoon ToDoList, который хоть и не вершина удобства — но хотя бы не ограничивает меня.
что-то мне подсказывает, что вы просто «захардкодили» в структуру все свои «фильтры». Само по себе древовидное представление может быть и обеспечивает большую гибкость, но после того, как структура была создана — она ее теряет. Фактически, система заточена под руководителя. А конечный исполнитель вынужден приспосабливаться. Хозяин — барин, как говорится.
«захардкодили» в структуру все свои «фильтры»
Кхм, не понял что и куда я захардкодил.
Есть большое, страшное дерево
Верхние узлы = Проекты
Этот уровень меняется довольно редко
Проекты бьются на Задачи или Задачки
Задачи бъются на Задачки
Задачки могут оказаться крупноватыми и либо перенесутся уровнем выше, либо разобьются на Задачечки.
У всех элементов есть Приоритет и Тэги
Дерево дает наглядный обзор:
Где что и в каком количестве ждет решения.
Что из чего состоит.
Что от чего зависит.
Для обзора и планирования — смотрю и правлю дерево.
Для выполнения — смотрю в плоский список с сортировкой по Приоритету и Тэгам.
Можно убрать (или ограничить до двух уровней) дерево — которое по неизвестной причине вызывает идиосинкразию.
Но тогда придется усиленно плодить тэги, и фильтровать по ним.
Соответственно наглядность сильно ухудшится.
Насчет «система заточена под руководителя»
Я эту систему и никому не навязываю, использую для себя.
В данный момент у меня остался всего один сотрудник в «группе», он планирует дела так — как ему удобно.
Я со своей стороны вешаю Тэг «Контроль», на задачи которые отдаю ему, и скажем Тэг «План-Неделя» для своих задач.
Мой непосредственный руководитель кстати тоже мне ничего не навязывает, отдает мне задачи и ставит себе на контроль.
На самом деле тут можно спорить долго.
У всех своя жизнь, свои принципы и свои инструменты.
Но обсуждать и делиться своим опытом — таки полезно :)
Я эту систему и никому не навязываю, использую для себя.
В данный момент у меня остался всего один сотрудник в «группе», он планирует дела так — как ему удобно.
Я со своей стороны вешаю Тэг «Контроль», на задачи которые отдаю ему, и скажем Тэг «План-Неделя» для своих задач.
Мой непосредственный руководитель кстати тоже мне ничего не навязывает, отдает мне задачи и ставит себе на контроль.
На самом деле тут можно спорить долго.
У всех своя жизнь, свои принципы и свои инструменты.
Но обсуждать и делиться своим опытом — таки полезно :)
я собственно просто обсуждаю недостатки абстрактного дерева задач :)
Так вот, например, дерево группирует задачи по Проект/Регистратор/Домен. А бухгалтеру было бы удобнее видеть Регистратор/Дата (месяц) продления/Домен. И он как-бы пролетает мимо дерева, потому что структура рассчитана на другое.
Это просто грубый пример. Суть в том, что древовидное представление это по сути некоторый способ группировки, который никак не может быть универсальным для всех случаев.
Лучше иметь плоский список, но продвинутую систему фильтров/группировок, через которые и формировать представление адекватное решаемой задаче.
Так вот, например, дерево группирует задачи по Проект/Регистратор/Домен. А бухгалтеру было бы удобнее видеть Регистратор/Дата (месяц) продления/Домен. И он как-бы пролетает мимо дерева, потому что структура рассчитана на другое.
Это просто грубый пример. Суть в том, что древовидное представление это по сути некоторый способ группировки, который никак не может быть универсальным для всех случаев.
Лучше иметь плоский список, но продвинутую систему фильтров/группировок, через которые и формировать представление адекватное решаемой задаче.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
У нас реализован именно такой подход. Мы также считаем, что иерархии в некоторых случаях — лишние. см habrahabr.ru/company/prettytasks/blog/201084/
Напомнило картинку: «Программист! Даешь понятный интерфейс!»
Представляю сколько это человекочасов и мозгодней. Вы молодцы. И, уверен, найдёте свою аудиторию среди тех, кто не боится разбираться.
НЛО прилетело и опубликовало эту надпись здесь
Столько комментариев про непонятный интерфейс и ни одной ссылки на пример понятного. Вот как должен выглядить понятный интерфейс — habrahabr.ru/post/144489/
А зачем задачи организовывать в деревья?
Хорошая попытка!
Автору респект и уважуха за то, что не поленились и довели до более-менее промышленного состояния.
При этом, хочу заметить что сейчас достаточно много готовых онлайн — сервисов. Из того, что наиболее похоже на ваш — mylifeorganized.net — дает замечательную иерархию + офлайн-синхронизацию.
Papirus.net — вложенность задач и разделение доступа.
Возможно там найдете вдохновение для модернизации своего интерфейса( а это важно для действительно массового продукта).
Удачи!
Автору респект и уважуха за то, что не поленились и довели до более-менее промышленного состояния.
При этом, хочу заметить что сейчас достаточно много готовых онлайн — сервисов. Из того, что наиболее похоже на ваш — mylifeorganized.net — дает замечательную иерархию + офлайн-синхронизацию.
Papirus.net — вложенность задач и разделение доступа.
Возможно там найдете вдохновение для модернизации своего интерфейса( а это важно для действительно массового продукта).
Удачи!
а можно новый корень меток как-нибудь создавать? А то у меня только вложенные
Умер проект, да?
Может кто-то подскажет что-то аналогичное и интеграцией в гугловую экосистему?
Может кто-то подскажет что-то аналогичное и интеграцией в гугловую экосистему?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сервис онлайн управления задачами, наш взгляд