Как стать автором
Обновить

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

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

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

Структуры навигации, это вообще ахтунг, кому и зачем это нужно - непонятно. Поиск с автоподстановкой решает задачу нахождения нужной информации в разы быстрее.
не решает. ибо информация может иметь одинаковые имена или незапоминающиеся имена и искать просто нечго
> ибо информация может иметь одинаковые имена
А поиск, по вашему, может выводить только один результат?
> незапоминающиеся имена и искать просто нечго
Искать нужно контент, а не названия.
Алгоритмы поиска информации - это самое важное над чем надо думать при создании проекта, и они не сводятся к тупому использотванию LIKE или FULLTEXT.
>А поиск, по вашему, может выводить только один результат?
еще раз говорю, чтобы искать нужно знать что искать, вместо того чтобы потом просматривать все что нашел и выбираеть еще там временами гораздо проще найти это в семантическом дереве, где каждая ветка несет смысл, заложенный самим же пользователем...

>Алгоритмы поиска информации - это самое важное над чем надо думать при создании проекта

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

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

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

Поиск не должен быть супер, он должен решать задачи пользователя.

Все можно оптимизировать если правильно идти от задачи. Единственное, что может реально ограничивать - это время разработки. Увы, оно губит все красивейшие начинания.
вот именно.
все что вы говорите верно с учетом того что вы начинаете новый проект где вы предоставлены самому себе. а теперь представьте приходите вы на новую работу. вам дают список проблем.приложению уже почти 10 лет и все это время оно развивается, дорабатывается , имеет просто огромные базы данных и тучу клиентов. в таких условиях 90% предложений, будь они хоть гениальными в плане удобства и юзабилити просто физически нельзя сделать потому как нужно переделывать все, абсолютно все...и займет это при текцущем штате несколько лет.

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

ваши действия?
Мне сложно ощутить вашу ситуацию, потому что я как раз специализируюсь на частичной или полной модернизации информационных структур компании на ходу.

примерно так: http://youtube.com/watch?v=M3hge6Bx-4w

И я знаю способы как "невозможно" сделать реальностью.
мне страшно за ваших клиентов))))) вы бы как пассажир полетели на таком самолете?

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

Всегда же можно придумать как, важно хотеть.
в общем случаи бывают разные
Но, тем не менее мы с вами аргументированно выразили две точки зрения. Мне было интересно с вами дисскутировать. Спасибо.
я не дешевка какая-нибудь. за спасибо не работаю...$6.50 )))
инвойс вышлю почтой
"Тюлюлю. Аппарат абоненты выключен или находится вне зоны доступа сети"

Упс... похоже вас кинули... :)))
Рекоммендую вам в следующий раз брать предоплату (хотя бы 30%).

PS. у меня жутко глючит хабр.
говорила мне бабушка "не ведись на сетевые разводы..."
Хе, в такой же ситуации на текущей работе. проект стартовал в 97 году.
Действия:
1. расстановка приоритетов
2. распределение времени исходя из первого пункта(в моем случае 35% на нововведения(не считая "скачков" когда месяц-два отводиться на нововведения глобального уровня, тогда 80%) и 65% на так сказать "обслуживание" системы)
Так вы говорите о динамическом(исходя из действий пользователей и их потребностей которые проявляются в процессе использования ресурса) дереве или статическом(созданным разработчикам исходя из виденья модели поведения пользователей)?
По поводу нагрузок и 10...: все зависит от ресурса, иногда жертвуем и жертвы наши не напрасны, поиск оптимального пути решения проблемы - задача разработчика.
есть предустановленные ветви дерева, которые изменяются только разработчиками, есть кастомные разделы где пользователь волен творить все что ему угодно...в хорошем смыле
В отношении "деревьев" - поддерживаю подобную модель, для себя ее понимаю как "разработчик задает вектор - пользователи развивают"
ну я ее понимаю так: мы делаем то что нужно, а пользователю даем возможность сделать так как он хочет, и чтобы вместе это все работало
Скорее всего, я немного не в теме, раз не понимаю: "Почему вы так кидаетесь на деревья?". Я, к примеру, иногда, по собственной инициативе создаю раздел "Карта сайта" в проектах, над которыми работаю. И там списками в виде дерева вывожу структуру сайта.
В случае разделов "Карта сайта" приемлемо ли выводить в виде дерева структуру сайта? Ни в коем случае не хочу вступать в бессмысленные споры, просто хочется понять все "за" и "против".
А вы когда нибудь задавались вопросом: "Зачем нужна карта сайта?" или "По какой причине карта сайта может понадобиться пользователю?"
В основном, для поисковой оптимизации =)
Сам иногда пользуюсь на уж больно заковыристых сайтах.
если вы делаете ссылку на карту сайта для поисковых роботов, это один вопрос, тут я с вами полностью согласен. Но мы то про полезность для пользователя говорим. 90% сайтов сделаны так, что на них ничего не найдешь и это они пытаются компенсировать наличием раздела "карта сайта", который тоже очень редко бывает полезен... И поэтому не следует уподобляться этой практике.
Я если честно, не сторонник вообще какого-то ни было усложнения, ибо из-за него все беды. По мне так лучше движок, представляющий собой образно две палки, соединённые гвоздём =) На таком движке и пишется проще сайт.
Сам лично считаю полезным реализовывать поиск по сайту таким образом, чтобы находить все словоформы и т.п. + можно собирать статистику запросов.
Разрешите уточнить: все словоформы по "направлению" ресурса + сбор статистики на основе которой происходит оптимизация "находимости" "ключевой" информации исходя из Действительных действий пользователя.
Если честно, не отслеживал, как распоряжаются статистикой.
Из библиотеки просто извлекаются все формы, которые может принять искомое слово. Никакой привязки к тематике ресурсов.
Не есть гуд, очень очень.
Согласный - перефразирую - если сайту нужна Карта_сайта - дальше по тексту. :)
Грамотно (это слово очень существенно) заполненное дерево в определенных случая (это слово тоже очень существенно) делает поиск (пусть даже самый распрекрасный) излишним.
Например (из практики) - есть электронный каталог на 40000 позиций. В каталоге представлена куча всякого барахла - от сверел до электростанций - всего где-то 1000 товарных групп, каждая со своими характеристиками. Соответственно, на сайте установлен поиск, который позволяет искать как по названиям, описаниям, текстам, или артикулам, так и по отдельным характеристикам.
Когда-то очень давно каталог представлял собой практически плоскую структуру (уровень вложенности - 1). Правда, тогда и товарных групп было поменьше (кажется 10), и позиций тоже (вроде бы 800). Поиском в тот момент пользовалось в среднем около 25% посетителей.
Потом структура каталога стала древовидной (каталог организован в виде дерева с вложенностью где-то 8), количество товаров увеличилось, количество товарных групп увеличилось, количество товаров в каждой группе увеличилось, а количество пользователей поиска уменьшилось до с веселой цифры 0.69%.
А поиск выглядел как или было куча комбо/чек боксов радиобатонов и т.д.?
А поиск выглядел <input type="text" /> как или было куча комбо/чек боксов радиобатонов и т.д.?
на первой странице - просто инпут + ссылка на расширенный поиск. Расширенный - как чекбоксы если это наличие признака, одиночные поля ввода, если это текст, двойные поля ввода - если это математический диапазон от и до, селект если это выбор из нескольких значений. Набор признаков для каждой товарной группы - свой.
если человек точно знает, что он ищет, он вколачивает на первой название или артикул, или, на худой конец, название товарной группы
Если не знает - лезет в расширенный поиск и ищет уже там
Мне кажется, наличие расширенного поиска как раз и пугает людей. Если его убрать и оставить только инпут, под которым писать примеры запросов, то это приучит пользователей юзать его эффективнее.
Не могу представить себе почему человеку проще открыть секцию Дрели->Ударные->Bosch, чем написать "Дрель Бош" в инпут и потом увидеть доп. фильтр "только ударные" (как более сложный сценарий).
В приведенном случае, если человек указал название агрегата, который он хочет регистрировать, представленный на картинке "2-й шаг" является преступлением против юзабилити. Если вдруг у них есть несоклько устройств разных типов под одним и тем же названием, можно было бы кинуть их списком с радиобуттоном.
Хотя, возможно цель у людей была другая - типа регистриует человек свою технику, а мы ему покажем, что у нас еще куча всякого разного есть - мож купит? Типа как пирожок в бигмачной...
Цель была, логики не было.
>Хотя, возможно цель у людей была другая - типа регистриует человек свою технику, а мы ему
>покажем, что у нас еще куча всякого разного есть - мож купит? Типа как пирожок в бигмачной...

На обороте коробки любого товара D-Link есть прекрасная секция "Works with", которая перечисляет, что еще может захотеть купить польователь впридачу к тому, что в коробке. Очень удачное решение того, о чем вы говорите имхо.
во всяком случае удачнее, чем у Зухеля
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории