Подходы к реализации меню

Существует 3 подхода к реализации меню. Первые 2 подхода используют ручное составление списка выводимых объектов. В первом подходе объекты (документы) причисляются к меню через интерфейс редактирования объекта (документа). В этом случае удобнее добавлять (и удалять) объект сразу в несколько меню, однако состав меню проявится только на сайте. Во втором подходе работа ведётся с самим объектом меню, агрегирующим необходимые объекты через собственный интерфейс. В этом случае удобнее быстро менять состав меню, т.к. нет необходимости лезть в соответствующие объекты.

В третьем подходе меню составляются автоматически, согласно некоторым предопределённым правилам вида: все дочерние документы, от документа c id=4, сортируя в порядке createdon DESC (использовать дату создания + последние в начале). Очевидно, что третий подход облегчает пользование CMS — новые статьи и т.п. не нужно каждый раз добавлять к меню, однако жёстко детерминирует как структуру вывода, так и структуру дерева документов. Впрочем, последнее, в большинстве случаев играет только на пользу качеству сайта: его понятности, предсказуемости и т.д.

Внимательный читатель уже понял, что первый подход — это Push-вариант, второй — Pull-вариант. Эти подходы являются конкурирующим, т.к. решают идентичные задачи концептуально различными образами. Представляется, что одновременная реализация двух этих подходов будет создавать путаницу для пользователей. Третий подход, напротив, отлично сочетается с каждым из первых двух. Тогда возникает вопрос выбора между вариантами 1 и 2.

Вариант 1:
недостатки:

• объект меню отделён от состава меню. Блокировка меню и т.п. будет выполняться в ином месте, чем причисление к меню
• порядок следования пунктов задаётся косвенным образом
• создание вложенных меню требует дополнительных сложностей, особенно в интерфейсе. В варианте 2 вложенность может задаваться очень просто:
  1
  2 (21, 22)
  3

Вариант 2:
недостатки:

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

Предварительный вывод — вариант 1 больше подходит для часто изменяемых меню и меню с большой сложностью итоговой структуры, в то время как вариант 2, наоборот больше подходит для редко изменяемых меню и меню с ограниченной сложностью.

Сама концепция меню подразумевает постоянство, гомогенность, простоту. Специалисты по интерфейсам рекомендуют ограничивать размеры меню в восемь и менее пунктов. Из всего сказанного следует вывод — вариант 2 является более «натуральным». Своими недостатками он подталкивает пользователей в правильную сторону, в отличие от варианта 1, который побуждает создавать гигантские нечитаемые меню подобные друпаловским монстрам.

Следует отметить, что вариант 1 является значительно более распространённым среди CMS. Скорее всего, причина тому в банальном повторении идей ведущих проектов.

Автор: Клешнин Иван