Устанавливаем программу - "Ок", установить в текущий каталог - "Ок", использовать установки по умолчанию - "Ок", удалить все и отформатировать диск - "Ок" ... бабах! Ой, что это я только что нажал и самое главное - почему? Интерфейс предназначеный для работы с людьми должен быть рассчитан на их привычки, в том числе и на непроизвольные реакции! Толковый материал об одном аспекте проектирования интерфейсов от Aza Raskin - Never Use a Warning When you Mean Undo на Alistapart.com.
Бонусом, в продолжение темы более свежий материал уже на Humanized - Undo Made Easy with Ajax того же автора.
Разрабатывая ЧПУ для CMS, я обращаю внимание на 3 основных аспекта:
По первому аспекту идет тихая война между приверженцами календарного и иерархического способов. Причем война не особенно обоснованная, поскольку каждый из способов показывает свои преимущества в конкретных приложениях: первый хорош и удобен в блогах, второй соответственно в информационных системах, регулярно пополняемых материалом, не имеющим жесткой привязки к календарной дате. Я совершенно искренне недоумевал, почему и в блогах нельзя использовать только 2-й способ - пишем site.com/blog/unikalnoe_nazvanie_materiala - и никаких проблем? Но у первого есть 2 неоспоримых преимущества: легко получать материалы за определенный временной промежуток, и очень легко формировать навигацию. Правда любой материал получает длинный адрес site.com/blog/year/month/day/some_else - выглядит не очень(например, как в этом блоге, построенном на InTerra), но зато очень удобно для пользователя - никто не мешает ему отсечь кусок урла в адресной строке и посмотреть, например, что автор писал за период site.com/blog/year/month/. Такой фокус трудновато проделать, если тот же календарный способ используется с формированием полного адреса в одном виртуальном каталоге - site.com/blog/year-month-day/some_else - не всякий пользователь догадается, что и как именно убрать из адреса, чтобы просмотреть интересующий его период. Однако при нормально построенной навигации такой подход мне представляется надуманным, как впрочем и разработчикам навигации сервиса Blogspot - в этом легко убедиться, посмотрев как устроена навигация по архивам публикаций любого пользователя за любой период. В любом случае, исповедуя "человекопонятность", необходимо помнить что один взгляд на урл должен говорить читателю - где он находится, без догадок - /blog/ - значит блог, /shop/ - значит магазин. Причем цифры после /blog/ ясно говорят пользователю что это скорее всего дата, а вот после /shop/ должно стоять /anal_toys/ а уж вовсе не /86tge987yhf9h_/ - такой подход и parental control кстати облегчит :) В блоге или в разделе новостей корпоративной CMS оправданно будет сохранить двойную навигацию - как по хронологии, так и по тематическим разделам, в остальных навигационных блоках вполне досточно будет формировать ЧПУ используя реальную или виртуальную иерархическую структуру разделов.
Второй аспект тоже вызывает немало головной боли. Одни поисковики больше "любят" страницы с меньшим уровнем вложенности, другим это абсолютно равноапостольно. Дорвейщики этот факт знают и дабы не рисковать, генерируют дорвеи в которых все файлы контента находятся в корневой папке и имеют уникальные имена. Это дает быструю индексацию контента Гуглем и выдачу его в результатах поиска в кратчайшие сроки - до бана, если повезет, сутки-трое такой сайт проживет. Нас интересует другой момент - просто адекватная и быстрая индексация контента. К примеру, один мой недавний материал я опубликовал также на форуме searchengines.ru. Через 3 дня смотрим запрос по точному названию материала - есть выдача с форума (1-й уровень вложенности), есть даже с моего ЖЖ (1-й уровень, проиндексирована главная) - а на моем блоге индексация главной закрыта, и сама статья, находящаяся на 4-м уровне, ждет своей поры. Не принципиально, что я закрыл индексацию - обычно большой материал не бывает доступен с главной страницы - как правило есть 2-3 абзаца в анонсе и ссылка на постоянный адрес - а он может ждать своей очереди долго, и иногда, если кто-то успеет скопировать материал - то попадает в сапплиментал и прощай трафик. Таким образом, у приверженцев длинных иерархических URL появляются противники с серъезными аргументами. Как с ними бороться - каждый решает по-своему, я пока не определился какую сторону принять, но проблема есть и решать её надо.
Принципы использования ЧПУ для управления навигацией с помощью mod_rewrite довольно просты - построение ЧПУ должно быть непротиворечивым и не входить в конфликт с первыми двумя аспектами по возможности. Непротиворечивость реализовать просто, опять на примере используемой CMS - если после адреса сайта в строке цифра - это скорее всего календарный урл, скрипт проверяет и выводит публикацию, если она существует; если слово - это вероятно название раздела. Угу, я обновил Интерру до новой версии и оказалось что раздел Ajax недоступен - разработчик, недолго думая зарезервировал это слово, как служебное в новой версии, функция-обработчик теперь интерпретирует именно этот запрос по-другому, в результате мой сайт поломался (don't worry, я все починил)! А ведь в том же Wordpress-е уже дано пришли к простому решению - зарезервировать для служебных слов определенный префикс, и всего делов - wp-admin, wp-login и так далее, а если пользователь пытается создать раздел в корне сйта с таким же названием - мягко, но твердо наставить на путь истинный. Берем принцип на вооружение. А вот с бесконфликтностью я думаю придется идти на хитрости. Первый аспект нам ничем не угрожает, а вот глубина вложенности материала создает определенные проблемы для своевременной индексации поисковиками. Как полумеру, я принял для себя такое решение: ссылки на свежие материалы блога с главной страницы формируются как site.com/quick_year_month_day_some_else.php - обработчик ловит служебное слово quick (на самом деле читаем абзац выше и придумываем своё слово правильно), выдает 301 и редиректит уже на "правильный" адрес. Но редиректит не сразу после публикации. а потом, через заданное время, например через пару месяцев, а до тех пор материал спокойно проживает по двум адресам, один из них будет в выдаче, второй видимо в сапплиментале - это не смертельно.
Засим закругляюсь, с удовольствием выслушаю мнения авторитетных товарищей
Kevin Roth наконец добавил кросс-браузерности и настраиваемости своему знаменитому wisiwyg редактору – теперь он без проблем работает с Opera9 и Safari, также в новой версии легко настраиваются кнопки панели управления. В self-made CMS однозначно!
upd: новая версия 3.03 и конец открытого кода: исполняемый java-script файл зашифрован и сжат (что не есть большая проблема), исходники можно легально ... приобрести за 49 у.е. Прощай open source редактор, жаль...
Чтобы не путаться, сразу определимся – Content Management System (CMS) – это система именно управления содержимым сайта. Не движок сайта, The Site Engine (TSE – чтобы не путать с SE), а система управления его контентом. Давайте отделим мух от котлет: программисту – движок, дизайнеру – пардон, дизайн, а менеджеру – контент. Сейчас поясню разницу.
Что такое сайт в данном контексте? Это набор скриптов и документов (неважно – статичных, или создаваемых динамически), а) связанных навигацией (то есть каждый документ имеет уникальный адрес и путь, который нужно пройти к нему), б) имеющих (как правило) единый дизайн или варианты дизайна, выполненных в одном из распространенных форматов представления данных, в) объединенных общей информационной структурой, г) обладающих заданными параметрами отображения и собственными характеристиками. Повторяюсь, это – описание сайта, сделанное разработчиком, рассматривающим сайт с точки зрения управления контентом. Рассмотрим только интересующие детали:
Навигация, наука о прокладке путей и безопасном кораблевождении – она же список блюд, меню. Движок сайта (системы отображения контента) весьма желательно должен обеспечить автоматическое создание навигации по контенту – то есть явно указать пути ко всем разделам и конкретным документам. Таким образом, управление созданием меню в задачу CMS не входит. Сразу уточним, что задачей системы управления контентом будет поддержание ясной и непротиворечивой информационной структуры сайта, позволяющей движку автоматизировать создание меню, карты сайта (бесполезной, но столь любимой поисковиками), RSS-фида и любого другого продукта, являющегося результатом обработки данной структуры.
Дизайн: как правило шаблонный – main.tpl + style.css либо набор темплейтов-кубиков для разных разделов сайта + стили (скин), может быть не в единственном экземпляре. Редактированию из CMS также не подлежит, так как контентом НЕ является.
Структура документа, основные типы:
Таким образом, мы определились с идеологией и обозначили – чем именно будет заниматься наша CMS, какие объекты будут её целями, а какие – в другой епархии. Задачи уже тоже, кажется, полностью ясны – создание новых объектов и управление имеющимися – редактирование и удаление. Последнее не означает, что мы можем только редактировать, нет. Мы сможем создавать новые документы, списки, древовидные иерархии объектов, изменять параметры и назначения активных скриптов – но это должно логично вписываться в существующую информацинную структуру сайта.
Просто великолепная статья "CMS на самом деле" – не исчерпывающая темы, но, по моему скромному имху, ее надо давать читать всем девелоперам. Кто отвернется – по зубам – и заставить выучить наизусть. Для контраста – творение очумельца, который эту статью не читал (линк не на первоисточник, специально, да). У него все по отдельности верно, только в итоге получается сферический конь на 3-ядерном процессоре... о людЯх думать надо, а не о том, как всучить побольше кода заказчику.В общем, этой заметкой открывается серия публикаций «CMS делаем сами». Периодичность 1-2 раза в неделю/месяц. Пишу в основном для себя, но буду благодарен друзьям а равно и незнакомым людям за комментарии, если носом ткнут – тоже спасибо. Первая заметка будет называться – «Цели и задачи CMS»
Ajax