На заре появления первых систем управления сайтом, практически у 100% веб-студий присутствовало абсолютно, не побоюсь этого слова, бредовое УТП — «заказывайте разработку сайта именно у нас — после создания, обновлять его сможет любой!». И все бы ничего, но с развитием Интернета мы уже убедились в том, что тысяча обезьян, посаженная на пишущие машинки, все же не смогла написать «Войну и мир».
По неизвестной науке причине, основная часть заказчиков свято верит, что нет ни малейшей необходимости вкладывать дополнительные средства в поддержку сайта и они могут со всем справится сами. Ведь сайт был заказан с системой управления, все должно работать идеально — какие бы изменения в сайт не вносились.
При этом забывается тот факт, что CMS — это не конструктор Лего с полностью взаимозаменяемыми деталями, а лишь набор кубиков, каждый из которых подпиливается напильником для придания ему формы октаэдра или тетраэдра. И если напильник попадает в неумелые руки, то результатом скорее всего станет разрушение всей конструкции.
Именно о таких ситуациях мы сегодня и поговорим.
Вообще, есть два типа заказчиков — первый долго и вдумчиво доносит свои идеи до дизайнера/разработчика, требует по сто раз передвигать блоки, менять форму и содержание, но в результате получив свой «домик» успокаивается и наслаждается легкими мазками краски по фасаду.
Второй тип делает практически тоже самое, но только лишь получив в руки административную панель сайта, сразу же начинает изменять его под свои новые идеи, кардинально отличающиеся от тех, которые были при старте проекта. При этом абсолютно не учитывается тот факт, что логика разработки изначально строилась абсолютно иначе — на основе ранее высказанных пожеланий и требований. В итоге, все это заканчивается абсолютно закономерной ситуацией — у сайта, как у детской машинки, отлетают «колесики» и он отказывается «ехать» дальше.
В качестве примера могу привести недавнюю ситуацию — заказчик просит сделать каталог товаров на основе отдельных страниц. Объясняется это тем, что, мол — у нас очень разный товар, абсолютно разное описание для каждого, каталог с фиксированными полями делать нельзя, а шаблоны под каждый товар мы подготовить не можем — шибко разная продукция. Магазин не нужен — есть необходимость только в каталоге, поэтому привязка к корзине не нужна. А страницу — как хочу, так и делаю, и все проблемы решены. Кроме того, на стартовой должны сразу выводиться рубрики каталога. Ок, все более-менее логично — на том и порешили.
Делается скелет каталога, вся схема создания рубрик, изображений к категориям и их описания разрабатывается под управление из административной части, все как положено — никакой правки кода со стороны заказчика и прочей ереси. Первая страница «Каталог продукции» формируется из вложенных и выводится на стартовую. Разработка, тестирование, демонстрация, запуск.
Знаете что заказчик сделал первым делом? Он удалил страницу «Каталог продукции». Вся логика, соответственно, рухнула как карточный домик. На вопрос — «зачем?» последовал ответ: «Мне не понравилось название страницы, я хотел ее переименовать».
Не меняйте бездумно то, что разработчик опубликовал в качестве примера. Если нужно внести изменения — используйте наработанную структуру. Если изменения более кардинальные, чем вы предполагали с самого начала — уточните у разработчика, какие изменения можно вносить и к чему это может привести.
При этом обратим внимание, к сайту полагалась инструкция на 10 страницах, в одном из разделов которой четко и по-пунктно было написано — что и как нужно сделать для изменения названия страницы. Но кто ж ее читает, инструкцию-то?
Если с самого начала я предоставлял полный административный доступ заказчикам к созданному сайту, то в определенный момент стал ограничивать доступ либо с помощью прав — для сайтов, либо через отключение доступа к определенному функционалу — для блогов. Как показала практика — этот метод снимает массу вопросов и избавляет от последствий влияния шаловливых ручек клиентов на работоспособность сайта.
Всегда внимательно читайте инструкцию. Обязательно оговаривайте ее создание еще на этапе договора о разработке. Если возникают дополнительные вопросы — попросите разработчика дополнить инструкцию их пояснением.
Еще один момент, на котором спотыкается 99% новоиспеченных администраторов — визуальный редактор. Знаете, что не умеет делать 95% пользователей Word? Использовать стили для оформления текста. Они привыкли банально менять размер шрифта и сам шрифт для документа и переносят свои умения и на WYSIWYG.
Помноженное на личный вкус — огромный шрифт, розовые буквы, тысячи восклицательных знаков — от всех потуг разработчика организовать хоть какое-то подобие юзабилити после всех правок дизайна, не остается и следа. Хотя, каждый принимается на работу как «опытный пользователь офисных приложений» и знать что такое стили — просто обязан.
Уточните у разработчика, какие стили оформления используются для элементов сайта. Попросите составить таблицу соответствий и используйте ее неукоснительно. Если нужен новый стиль оформления — доработайте CSS, но не вставляйте форматирование непосредственно в код. В случае редизайна сайта, такой подход избавит вас от необходимости вносить изменения в каждый элемент контента.
О вставке текста непосредственно из Word я уже даже не говорю, как и о том — во что превращается код страницы после таких «изысков». Причем я для интереса проводил эксперимент — над полем редактора пламенела ярко-красным цветом надпись: «Тексты, изображения и таблицы из Word — не вставлять!» Вы думаете, это существенно помогло?
Не вставляйте текст непосредственно из Microsoft Word или любого другого текстового редактора (исключая блокнот). В визуальный редактор сайта должен попадать так называемый pure text — или текст, без оформления. Дальнейшее форматирование текста — жирный, курсив, подчеркивание, нумерованные и маркированные списки и т.д. — должно проводиться только средствами WYSIWYG.
Следующим «подводным камнем» становится изменение настроек. В WordPress, например, любимым действием является смена стартовой страницы и отключение плагинов. В первом случае мотивация «а я хочу, чтобы в первую очередь была страница обо мне — ведь это же мой блог!». А то, что в шаблоне не была предусмотрена (нет смысла) хотя бы ссылка на общую ленту (не на категории) — не учитывается. В итоге все записи стали доступны только из рубрик.
Во втором — один из заказчиков отключил создание резервной копии, а после очередного падения кричал и в прямом смысле бился в истерике, что я должен был это предусмотреть и поставить дублирующую систему.
Даже если у вас есть доступ к глобальным настройкам сайта и его модулей — не меняйте их значения без согласования с разработчиком. Вы должны понимать, что даже самая простая настройка может критично повлиять на работоспособность сайта.
Внутренняя оптимизация сайта руками заказчика — это вообще нечто. Любое «а я вот прочитал у Васи Пупкина, что…» тут же, без малейшей оценки, внедряется на сайт.
Помню одного клиента, который где-то прочитав о том, что так будет лучше, сделал следующее — он удалил каталог и создал по одной странице на каждую категорию товаров. Далее, он на эту одну страницу затолкал все товары категории и опубликовал ее на сайте. В итоге получились огромные полотнища текста и картинок, длиной по 30 экранов и весом страницы порядка 5-7 мегабайт. На вопрос: «что это за ужас?» было сказано — «а я вот читал, что так правильно — все, что Вы мне до этого рассказывали о целевых страницах — это ерунда!».
При этом сайт уже был полностью проиндексирован, а по некоторым СЧ запросам самостоятельно занял топовые позиции. Закономерно понятно, что после такого вмешательства все покатилось под откос.
Если вы не знаете что такое оптимизация сайта или вы понимаете, что ваши знания недостаточны — не проводите изменения на страницах, в структуре или в ссылках. Согласовывайте изменения с разработчиком и оптимизатором, уточняйте у него влияние изменений на качество сайта. Помните, что от качества страниц зависит не только сам сайт, но и, например, ваши расходы на контекстную рекламу (параметр «Показатель качества» в Google Adwords).
Больше всего меня поражает упорство и настойчивость людей, выполняющих абсолютно бессмысленные действия, ведущие как к финансовым, так и к экономическим потерям. Зачем вкладывать деньги, время и ресурсы в результат, который заведомо будет проигрышным? Да, есть категория людей, которая чисто психологически настроена на то, что их все хотят обмануть. Буквально все — от продавца в магазине, кондуктора в трамвае и до разработчика сайта. С чем это связано — не знаю, то ли с тяжелым детством, то ли с жизненным опытом.
При этом есть и заказчики, использующие альтернативную описанной выше модель поведения — они будут внимательно читать инструкции и, более того, просить дополнять их нужными вопросами. Они будут задавать вопросы прежде чем нажать на любую неизвестную кнопку, они обязательно подстрахуются всеми возможными путями и лишь после этого что-то сделают, при возникновении любой нештатной ситуации они в первую очередь напишут и спросят.
Я не говорю о безоговорочном доверии к исполнителю — это нонсенс. Даже самый замечательный и всезнающий разработчик не может знать все тонкости вашего бизнеса и преимущества всех ваших товаров и услуг.
Но какой смысл заказывать полноценную разработку, долго и нудно согласовывать дизайн, прототип, структуру — платить за все это, если все равно в итоге все будет полностью изменено, причем особо варварскими методами?
Если у вас недостаточно опыта и нет сотрудников с соответствующими знаниями — оптимальнее заключить с разработчиком договор на поддержку вашего ресурса и оплачивать ежемесячно небольшую сумму, но зато быть уверенным в том, что — ваш сайт не станет очередным посмешищем и примером «как не нужно делать сайты», а будет полноценно работать, удовлетворять потребности ваших клиентов и приносить вам прибыль.
Двойная выгода в новом конкурсе с биржей TrustLink! Заработай больше всех и получи за это 15 000 рублей! Не медли, опереди своего конкурента и зарегистрируйся прямо сейчас.