Аналогично провел несколько «приятных» часов, в поте выясняя почему домен стал резолвиться на американский айпи. Причем у r01.ru первичный днс выдавал неверный айпи, а вторичный — правильный. Попытки что либо поменять в личном кабинете к успеху не привели — задания на смену данных вставали в очередь и не выполнялись.
Мы опубликовали «Хрестоматийный API» Сбербанка, — используя его, разработчики могут построить прототип банковского приложения. Предложить идеи как часть банковского продукта.
Ага, разработчики кинулись кодить приложения, чтобы потом Сбер их тупо отшил.
А мне вот интересно, продумывался ли конструкторами вариант с замерзанием выдвигающихся ручек. А то не особо приятно будет на морозе пытаться открыть обледенелую машину.
Да уж, заголовок… Пускай вычислят местополжение Сами знаете кого, когда у него твиты типа «Почесал яйки», «Чешу правую ногу».
Определение приблизительного часового пояса — да, это почти инновация, но погрешность в целые континенты может быть.
Выбрали Google Tasks в первую очередь (кроме его распространенности) из-за наличия почти безглючного и документированного API, корректной поддержки почти бесконечной вложенности задач (ооо, это отдельная песня). Плюс важный момент — чем сложнее и продвинутее сервис, тем сложнее с ним наладить полноценный обмен, пускай даже есть мощнейший API. К примеру, повторяющиеся задачи. У каждого — своя реализация этого (кто-то хранит все задачи, кто-то хранит только паттерны и ссылки на них), пришлось бы намного дольше разбираться.
Вложенные задачи нужны однозначно, это гораздо сложнее для разработчика в реализации, но для пользователя это однозначное благо, т.к. если нет необходимости — этой вложенностью можно и не пользоваться.
То, что у каждого свое видение структуры – есть такое, но это неизбежно, т.к. классическая древовидность предполагает одного родителя у узла дерева.
Вот про поиск и выдачу задач – действительно, не совсем понятно как удобнее выводить пользователю. Но это сложности разработчика. Навскидку – просто выводить рядом путь в дереве. Для большинства случаев хватит за глаза.
Мы тоже работаем над системой управления задачами, в ней постарались реализовать древовидность без каких-либо ограничений. Могу дополнить копилку сложностей всего лишь одним аспектом – разруливание возможных противоречий между родительской задачей и дочерними, если их допускать нельзя. Т.е., к примеру, если в родительской задаче установлены какие-то параметры, то и дочерние должны им соответствовать (если это важно). К примеру, сроки, бюджет, время и т.п. – должны ли сроки подзадач укладываться в сроки родительской и т.п. Аналогичная ситуация, к примеру, с метками задач или их аналогами – должны ли подзадачи их наследовать или нет. У каждого пользователя свои предпочтения.
Ну и по мелочи — у пользователей разное видение того, что должно произойти с подзадачами при выполнении родительской задачи. Кто-то считает, что должны быть автоматически помеченые как выполненные все подзадачи (как в Google Tasks), но это далеко не всем подходит. Аналогичная ситуация с родительскими задачами – что должно произойти при выполнении всех подзадач – должна ли родительская задача стать выполненной?
Самое некрасивое — стафф дропбокса ничего толком не говорит. Скоро уже будет как целые сутки часть папок недоступна (у меня). Судя по тому, что папки недоступны и из веб-интерфейса — дело может и не в версии клиента. Если даже вся информация и сохранится — крайне неприятным косяком будет большоей количество конфликтующих копий у пользователей, изменявших совместные файлы за время даунтайма, на форуме у них уже есть жалобы на это.
Ну не всегда подходят искусственно притягиваемые понятия вроде «проект».
Чтобы не быть голословным, обратимся к практике. Пускай одна (именно одна из) из областей, которые нужно отслеживать — домены/сертификаты/кредитные карты и т.п. Пускай домены. Пускай задача выглядит как «Продлить домен google.com». Доменов к примеру две сотни (это пример, я к SEO отношения не имею). Один из важных параметров, который нужно принимать во внимание — регистратор. Т.е. есть необходимость вывести список задач продления доменов именно по опредленному регистратору. Мы, к примеру, вместо доменов учитываем сертификаты в разрезе удостоверяющих центров, но не в этом дело. Для фильтрации именно по определенному регистратору нужно как-то эти задачи обособить (чтобы был какой-то критерий для фильтрации). Вариантов немало, но все они имеют недостатки по сравнению с иерархией.
Т.е. можно включать название регистратора в текст самой задачи. Костыль. Дай бог каждый раз написать правильно. Если данные вводит другой человек — также отслеживать чтобы вводили правильно.
Можно обособить эти задачи с помощью тэгов. Но тогда нам нужно городить кучу тэгов, которые в других задачах и не нужны и которые будут мозолить глаза. Делать иерархию тэгов — тоже скажете, что излишнее усложнение. И также нужно не забывать проставлять эти тэги.
Делать на регистраторов отдельные списки/проекты — тоже не решение. Когда их немного, можно и потерпеть, а когда много — проблема.
А вот с помощью иерархии делаем структуру типа Домены/GoDaddy/example.com.
И далее фильтрацией по папке получаем только задачи по продлению у регистратора GoDaddy.com. Это только один из примеров, которые продиктованы нам жизнью. Спросите, зачем нам такие запросы — к примеру, фильтрацией по удостоверяющему центру определяем список заканчивающихся сертификатов и предпринимаем меры (авансируем оплату разом).
Да, возможно большинству такие сложности не нужны, поэтому и не нашлось сервисов, грамотно реализующих учет таких задач. И поэтому пришлось городить весь этот огород.
Ну если вкратце — то иерархия нужна тогда, когда задач уже много. Также как и в случае с файловой системой — структура папки/подпапки удобна же. Так и в случае с большим количеством задач — объединение их в папки убирает их с глаз.
Teambox смотрели. Там иерархии нет вообще, точнее жесткая структура «проект — список — задача». Это, наверное, большинству подойдет, но нам не подходило. Попытались реализовать свое видение — первоначальное деление по спискам (на уровне списков настраиваются права доступа, некоторые триггеры, синхронизация), далее — простая иерархическая структура папок/задач.
И не стоит так категорично утверждать про два-три уровня. Как только задач больше сотни — иерархия необходима, это мое мнение. Да, частично можно обойтись без нее путем фильтров, тэгов и пр, но не всегда.
Так версия последняя, саму тему оформления (не только Метрополис) пользователь может выбрать в два клика, ткнув Settings-Theme. Я думаю, если бы скрин приложил в этой теме, то про дизайн претензий было бы чуть меньше. Хотя как раз для реальной работы она менее удобна — бордеров мало и прочий минимализм.
Тот вал информации, который Вы увидели на скринах — это, по сути и есть этот мусор в виде абсолютно всех задач. Чтобы сосредоточиться на конкретных областях — есть фильтры, к примеру «Список покупок», «Задачи, истекающие сегодня», «Задачи, истекающие в следующем месяце», которые пользователь сам и настраивает. Там выводится только нужная информация.
Аналогичный подход, кстати в программе MyLifeOrganized, там также в виде дерева вводится весь массив текущих задач, а потом нужные задачи фильтрами и в соответствии с настраиваемыми «весами» выводятся уже в виде списка.
В том то и дело, что иерархия просто необходима, когда задач очень много. 10-20 задач еще можно в одном списке видеть, но когда их за сотни (к примеру, однотипных, но которые учитывать нужно именно отдельно), то тогда без дерева не обойтись.
Молча соглашусь. Среди нас нет ни проектировщиков, ни дизайнеров. Все время уходило на функционал, а для приемлемости дизайна куплены devexpress`овые компоненты.
Ага, разработчики кинулись кодить приложения, чтобы потом Сбер их тупо отшил.
По-моему, Kirtland в New Mexico.
Определение приблизительного часового пояса — да, это почти инновация, но погрешность в целые континенты может быть.
То, что у каждого свое видение структуры – есть такое, но это неизбежно, т.к. классическая древовидность предполагает одного родителя у узла дерева.
Вот про поиск и выдачу задач – действительно, не совсем понятно как удобнее выводить пользователю. Но это сложности разработчика. Навскидку – просто выводить рядом путь в дереве. Для большинства случаев хватит за глаза.
Мы тоже работаем над системой управления задачами, в ней постарались реализовать древовидность без каких-либо ограничений. Могу дополнить копилку сложностей всего лишь одним аспектом – разруливание возможных противоречий между родительской задачей и дочерними, если их допускать нельзя. Т.е., к примеру, если в родительской задаче установлены какие-то параметры, то и дочерние должны им соответствовать (если это важно). К примеру, сроки, бюджет, время и т.п. – должны ли сроки подзадач укладываться в сроки родительской и т.п. Аналогичная ситуация, к примеру, с метками задач или их аналогами – должны ли подзадачи их наследовать или нет. У каждого пользователя свои предпочтения.
Ну и по мелочи — у пользователей разное видение того, что должно произойти с подзадачами при выполнении родительской задачи. Кто-то считает, что должны быть автоматически помеченые как выполненные все подзадачи (как в Google Tasks), но это далеко не всем подходит. Аналогичная ситуация с родительскими задачами – что должно произойти при выполнении всех подзадач – должна ли родительская задача стать выполненной?
Чтобы не быть голословным, обратимся к практике. Пускай одна (именно одна из) из областей, которые нужно отслеживать — домены/сертификаты/кредитные карты и т.п. Пускай домены. Пускай задача выглядит как «Продлить домен google.com». Доменов к примеру две сотни (это пример, я к SEO отношения не имею). Один из важных параметров, который нужно принимать во внимание — регистратор. Т.е. есть необходимость вывести список задач продления доменов именно по опредленному регистратору. Мы, к примеру, вместо доменов учитываем сертификаты в разрезе удостоверяющих центров, но не в этом дело. Для фильтрации именно по определенному регистратору нужно как-то эти задачи обособить (чтобы был какой-то критерий для фильтрации). Вариантов немало, но все они имеют недостатки по сравнению с иерархией.
Т.е. можно включать название регистратора в текст самой задачи. Костыль. Дай бог каждый раз написать правильно. Если данные вводит другой человек — также отслеживать чтобы вводили правильно.
Можно обособить эти задачи с помощью тэгов. Но тогда нам нужно городить кучу тэгов, которые в других задачах и не нужны и которые будут мозолить глаза. Делать иерархию тэгов — тоже скажете, что излишнее усложнение. И также нужно не забывать проставлять эти тэги.
Делать на регистраторов отдельные списки/проекты — тоже не решение. Когда их немного, можно и потерпеть, а когда много — проблема.
А вот с помощью иерархии делаем структуру типа Домены/GoDaddy/example.com.
И далее фильтрацией по папке получаем только задачи по продлению у регистратора GoDaddy.com. Это только один из примеров, которые продиктованы нам жизнью. Спросите, зачем нам такие запросы — к примеру, фильтрацией по удостоверяющему центру определяем список заканчивающихся сертификатов и предпринимаем меры (авансируем оплату разом).
Да, возможно большинству такие сложности не нужны, поэтому и не нашлось сервисов, грамотно реализующих учет таких задач. И поэтому пришлось городить весь этот огород.
И не стоит так категорично утверждать про два-три уровня. Как только задач больше сотни — иерархия необходима, это мое мнение. Да, частично можно обойтись без нее путем фильтров, тэгов и пр, но не всегда.
Аналогичный подход, кстати в программе MyLifeOrganized, там также в виде дерева вводится весь массив текущих задач, а потом нужные задачи фильтрами и в соответствии с настраиваемыми «весами» выводятся уже в виде списка.