Чего-то в конец достала текучка. Поэтому сегодня об абстрактном, а именно про древовидные представления данных, и вовсе нет. Зачем “деревья” хороши, а зачем и плохи… Потянуло, знаете ли, пофилософствовать.
Вот чем больше смотрю на LeaderTask, тем больше задумываюсь, ну на хрена там деревья проектов!?! А ведь не только смотрю, я ведь еще им и пользуюсь. Причем давно, и вообще говоря с удовольствием. В принципе среди перепробованных органайзеров, LeaderTask, пожалуй, лучший. И чего в LT только нет: и категории, и сроки задач, и напоминания, и контакты. Буду краток (©). LT – это именно органайзер, в смысле слова “организатор” – то бишь софтина для планирования дел и контроля их выполнения.
В LT есть возможность создавать дерево проектов, и подпроектов. К примеру, “софтина такая-то”, “домашние дела” ну и.т.д. Но в подавляющем большинстве случаев, мне, как пользователю, достаточно затруднительно привязать задачу к тому или иному проекту. Скажем, надо мне нечто анонсировать в RSS ленте про “софтину такую-то”. Ну и куда мне сие отнести? К проекту “софтина такая-то” или к проекту “веб сайт”? ОК, конечно, можно привязать задачу к обоим проектам сразу, но тогда становится затруднителен анализ запланированных дел. Копаемся в проекте “софтина такая-то”, а находим записи про RSS для проекта “веб сайт”. А они там явно не ко времени, т.к. вроде как анализировали мы совершенно иное, а вовсе не задачи по работе с веб сайтом... По крайней мере, такой разнобой должен все-таки отвлекать (анализируем же? планируем? а не бардак перебираем?)
К слову, деревья это явно наше родное, программерское изобретение. Чего уж тут лукавить. Ну любит наш брат разбить всё и вся на деревья, на общее и частное, на абстракции и конкретику. Чувствуется что-то до боли знакомое. Это наше всё. Но тут-то всё как раз ясно. На самом деле иерархии помогают нам управляться со сложностью, бороть и побеждать (“лажать, но не сдаваться” если в несколько в другой интерпретации :).
Но вот обычному пользователю частенько все эти шибко ветвистые, вложенные деревья не так уж надобны. Ну не представляю я себе пользователя, у которого в голове выстраивается что-то вроде такого дерева: “шкаф”, “полка вторая”, “папка слева”, “запись об RSS”. Как водится всё несколько зауряднее: папка с делами, и папка с порнухой фотками. И всё! И нет никаких вам “деревьев”. И никакой гипер-пупер-супер вложенности тоже нет. Для анализа, поиска содержимого подобных папок нормальному, широко распространенному пользователю вложенность вовсе не нужна. Ну максимум один-два уровня. А это уже не дерево, максимум “кустарник”.
Тот же Алан Купер неоднократно повторяет, “пользователю чужды деревья, ему скорее ближе списки” (пусть и вложенные). Конечно же, из любого правила есть и исключения. Если пользовательские данные нечто вроде каталога, то все эти иерархические деревья сильно выручают. Но на то оно и исключение, что скорее из ряда вон, чем общий случай. Имхо, каталогизация вообще по сути своей значительно ближе к нашим программерско-админским задачам. Да хотя бы потому, что уж больно они хорошо помогают применять правило “разделяй и властвуй”.
Это вовсе не критика LT как такового. Фиг ли критиковать? Есть старинная поговорка: “не нравится – сделай лучше”. Мне вот лично LT очень сильно помогает. Но проблема деревьев коснулась и его. Повод задуматься.
В чужой софтине, мне, как обычному пользователю, далеко не очевидны все приемы работы. Поэтому и “сбокуприлепленность” деревьев выглядит для меня более “выпукло”. Проблема-то явно остается значительно более общей. Вот в своей собственной Aml Pages я точно также снова задумываюсь: “ну на хрена мне эти деревья”. Но в своей собственной софтине у меня есть и еще вагон и маленькая тележка вариантов использования, поэтому, там я всегда найду способ без деревьев и обойтись. Но ведь должно же существовать и какое-то иное решение подобных проблем? Есть же способ работы с карточками – записали мысль, отложили, и забыли. Задача быстро записать, и с глаз долой, из сердца вон (угу, тот самый мозговой штурм). Уже потом берем стопку карточек и просматриваем, выбирая себе задачки, группируем, оструктуриваем их всеми мыслимыми и немыслимыми способами.
Но ведь должно же быть, какое-то толковое и более менее общее решение!?! Вот его и хочется отыскать! Если с LeaderTask, как с чужой программой, меня в первую очередь волнует решение для себя любимого. То с Aml Pages,приходится задумываться об общих, куда как более абстрактных решениях. Что делать с LT, вроде как понятно: есть API плагинов – время найдется, напишу себе именно то, что именно мою проблему решит. А вот с Aml Pages все не так-то просто. И главное, подобная дилемма занимает голову далеко не первый месяц. И забил бы давно, дык ведь любопытно же решить…
PS: а еще бредилось про графы… Диплом все ж про графы был. А когда-то был умысел написать с-о-о-о-всем иной, то бишь напрочь отличный от всех остальных менеджер контактов (угу, блин, я в курсе, что все девелоперы на определенной стадии писали записные книжки :). Дык в тех “контактах” тоже все на графы было завязано… Уж больно енти “графья” завсегда по жизни рядом “вращаются”. Ну да это уже совсем отдельная песня.
Докатился… Впервые, мой пользователь горько, долго и вслух сожалел об отсутствии бумажной документации по 
