Корни ошибок при создании сайтов или почему заказчики не понимают смысла интернета
Invite pending
Любой разработчик онлайновых решений для компаний, работающих в «консервативных» областях, сталкивался с удивительным подходом к веб-сайту со стороны заказчика: как к «шашечкам» из анекдота про такси. Есть — хорошо, нет — ну и ладно. Отношение к онлайну как к чему-то, слабо влияющему на бизнес, широко распространено. Слишком широко, чтобы списывать все на глупость бизнесменов и почитать его исключительно ошибкой.
Так уж сложилось, что автору, рекламщику по основной специализации, в этом году подвалила нехитрая халтурка от знакомых — выправить косо сделанный на популярной CMS ресурс одного оффлайного магазина — и дать совет, как его развивать. Справившись с основной частью работы, я очень сильно задумался. Настолько сильно, что заинтересовался проблемой и посвятил ее изучению некоторое время. Создавалось впечатление, что многие ошибки, отталкивавшие посетителей — которые и ошибками в прямом смысле слова назвать сложно — являются не фирменным знаком горе-разработчика, а практически стандартом для современных российских ресурсов. То же можно было сказать и о многих ошибках настоящих, полновесных.
Серфинг по рунету, казалось, подтверждал странный вывод. Получалось, будто многие веб-разработчики не знают самих основ — от HTML и CSS до элементарной верстки. И сайты не «срабатывают» именно по этой причине. Предположение было странным.
Тем временем исправленный сайт начал давать стабильный приток клиентов (чего отродясь не делал), а новый сайт фирмы, созданный уже лично мной с учетом увиденного, поднял этот показатель еще в несколько раз… Компания перестала рассматривать интернет как «шашечки» и дала приличный бюджет на рекламу в Сети — к нашему обоюдному удовлетворению.
Для самообразования я продолжил копаться в теме и, кажется, нащупал корни основных ошибок многих создателей сайтов. Именно наличие этих корней и превращает сайты из инструмента бизнеса в строчку на визитке, тем самым портя репутацию всем, подвизавшимся на ниве работы с ними.
Должен предупредить — я не скажу ничего нового для профессионалов, однако, судя по увиденному в сети, многим продающим свои услуги в качестве «веб-разработчиков» не мешало бы это прочесть.
Поехали!
Для начала следует и осознать одну простую вещь — каждая деталь сайта важна. Быть может, никто осознанно не считает сколько пикселей в отступе картинки от текста — но даже такая, казалось бы, мелкая деталь влияет на общее впечатление от ресурса. А именно от него зависит, будет ли сайт эффективен.
Никто не спорит, что использование CMS значительно упростило работу, особенно в случае, если на сайте присутствуют большие массивы информации. Однако живущая в людях надежду на халяву подкладывает неслабую свинью как разработчику сайта, так и его нанимателям.
Увы, слепая надежда на вариант «поставил-накатил шаблон-PROFIT» способна убить ресурс.
Как именно? Есть несколько вариантов.
1) Готовые шаблоны
Помните благословенные времена дайл-апа и порталов? Стоп. Вычеркните слово «порталы». Ему не место в одном предложении с эпитетом «благословенный». Каждый школьник, освоивший тег "" и сумевший открыть Frontpage ваял собственный портал, бессмысленный и беспощадный. Все они были сделаны по одному лекалу. Все использовали одни и те же куски кода. Кто-нибудь, кроме их создателей, посещал их? Вот-вот.
Нынешние времена мало отличаются от тех. Тысячи сайтов с одинаковыми шаблонами с одних и тех же сайтов-продавцов (или вообще торрентов), отличающиеся лишь мелкими деталями, логотипом, цветовой схемой и бэкграундом. Одинаковая организация подачи информации, одинаковые контейнеры… Да что тут говорить! Все это видели. Миллионы блогов на вордпрессе не могут ошибаться и все такое.
Напоминаю про правило пяти секунд на странице (ладно, может и не пяти, а восьми, к тому же есть разные варианты, но «пять секунд» звучит круче). За эти несчастные секунды пользователь решает, остаться ли ему на странице или свалить. Подумать над тем, как именно влияет стандартизованный дизайн (притом далеко не всегда отвечающий цели показать пользователю то, что ему надо) на отток посетителей оставляю читателю.
2) Сложные шаблоны
Эта проблема целиком и полностью вытекает из предыдущей. В попытках ее решить, не напрягаясь, продавцы сайтов идут на парадоксальный шаг — используют чужой сложный шаблон с обилием разнообразных свистелок.
Казалось бы — что тут такого? Слишком сложно — не слишком просто, задел на вырост, опять же. Однако чрезмерно сложный покупной шаблон способен добавить новых проблем. Особенно это характерно для Joomla, где простенький на вид шаблончик может разожраться на несколько «физических» шаблонов — каждый со своими css-файлами, конечно.
В возможном конфликте составляющих частей отредактированного «жирного» шаблона и кроется проблема. Не увиденный поломанный стиль может оттолкнуть пользователей — а заметить и выправить эту ошибку будет не так уж и просто. Да и сам сайт кое-где может начать подглючивать.
К тому же сложные шаблоны в той же джумле плохо переносят обновления системы.
3) Расширения, много и разные.
Чем больше расширений от сторонних разработчиков — тем веселее. В теории. На практике хорошей идеей будет проверять их на совместимость со всеми основными компонентами сайта и друг с другом.
Действует тот же принцип, что и в прошлом пункте — даже самая малая ошибка будет замечена пользователем и сыграет не в пользу владельца сайта. Увы, это действительно так работает. В то же время — чем более сложна система, тем больше вероятность, что где-то она засбоит.
4) Пиратский софт
Упомянутые проблемы и сами по себе не слишком приятны. Но сделать их гарантированно непереносимыми способно использование пиратских версий. На трекерах полно ворованных шаблонов, расширений и так далее.
Пользоваться подобным, конечно, давняя традиция, но, право же, подумайте сами — вы не писали этих инструментов. Их разработчики — люди. И, выпуская коммерческий продукт, они волей-неволей рассчитывают на возможность патчем поправить какую-либо неисправность. Поскольку CMS и их компоненты, по идее, должны регулярно обновляться, любое обновление системы способно сломать ворованные вами куски кода. Оно вам надо?
5) Выбор инструмента. А нужна ли CMS?
Конечно, если на сайте ведется постоянная работа с большим количеством контента, без CMS не обойтись. Но если ваша задача — сайт-визитка без десятков галерей и новостных лент, куда более логичным представляется использовать старый добрый HTML. Цээмски активно пытаются хакнуть боты. Написание полноценного шаблона отнимает время — и к тому же, если необходимо создать сайт на пять не обновляемых страниц, быстрее получится работать с HTML — ведь вы не будете ограничены необходимостью написания шаблонов, настройки модулей етс. Следовательно, при прочих равных HTML, возможно, окажется удобней.
Зачем использовать микроскоп вместо кувалды — и наоборот?
Обычное невежество не улучшает ситуации.
1) Незнание стандартов
Возможно, для кого-то это будет новостью, но на ранжирование сайтов поисковиками, влияет, в том числе, влияет и соответствие различным стандартам — как W3C, так и общепринятым стандартам структуры веб-страниц. Например, отсутствие h1 на страницах скажется отнюдь не позитивно. Зачем портить положение сайта в выдаче?
2) Незнание HTML
Пара лишних тегов title на странице тоже ситуации не улучшит.
3) Незнание CSS
Да, никто не будет под микроскопом разглядывать количество пикселей в маржине. Но впаивать взаимно конфликтующие стили, надеясь на «авось» — глупо. Глупее разве что считать, что структура построения материалов на сайте всегда будет единообразной — и потому не предусмотреть возможности легко и просто настроить стили в конкретном месте под требования момента, а жестко задать их в основном css. Различные прилипания картинок к краям контейнеров, смещения центровки… все это, столь часто встречающееся, растет из этого.
4) Незнание основ дизайна
Понятное дело, от разработчика сайта всегда хотят всего, побольше и желательно вчера. Однако наивно полагать, что даже отличные навыки в коде заменят дизайнера. Более того — хороший дизайн не есть красивый дизайн. Это дизайн, выполняющий свою работу. Дело в том, что у любого сайта есть своя задача. И дизайн служит ее выполнению не в меньшей степени, чем что-либо иное.
Именно от дизайна зависит, поймет ли пользователь, что нашел «то самое» за те несчастные секунды, что проведет на странице, решая, смотреть сайт дальше или закрывать вкладку.
Если у вас нет приличных навыков в дизайне (да даже если и есть!) хорошей идеей перед разработкой вариантов для заказчика будет просмотр западных сайтов аналогичных тематик/назначения. Кое-какие решения вполне можно творчески позаимствовать.
5) Любовь к стенам текста
Запомните, в интернете никто не читает. По крайней мере, если не имеет заранее цели прочитать что-то (именно поэтому вы сейчас читаете эту строку, и то не факт, потому что искать картинки мне влом). Стену текста можно скормить пользователю только когда он полностью уверится, что он там, где надо. Картинки в этом способны очень даже помочь.
Самый любопытный вывод, который я сделал для себя, изучая состояние сайтов «средней руки», а равно форумы пользователей CMS и прочих подвизавшихся на ниве разработки сайтов лиц — многие смертельно боятся лишний раз заглянуть в код. И это способно серьезно повредить облику сайта — а следовательно, и его эффективности.
1) Проверка валидности кода
Выше я писал об ошибках в html. Далеко не всегда их причина — незнание. Нередко неправильно настроенная CMS может дать аналогичную картину, сажая ошибки, теги с устаревшим синтаксисом етс.
Решить такие проблемы обычно просто, главное их обнаружить. Для этого достаточно посмотреть исходный код страниц сайта в браузере. Увы, многие этого не делают.
2) Исправление ошибок CMS
Нередко можно наблюдать различные баги в интерфейсе, обусловленные кривым кодом самой CMS. А как влияют проблемы с юзабилити на посетителей, всем, думаю, понятно. Как ни странно, во многих случаях вовсе не обязательно ждать патча. При минимальных познаниях и наличии инструментария (Firebug, например) эти проблемы можно решать самостоятельно.
Чтобы не быть голословным, приведу пример — Joomla (по моей версии — вообще самая глючная из популярных CMS) в версии 1.5 имела проблемы с компонентом блога, решаемые именно в коде. В версии 3.1.5 без использования напильника пользование админкой было несколько затруднено (например, при создании пункта меню невозможно было перелистывать страницы списка материалов, а только находить нужный поиском). И решалось все элементарно.
3) Создание собственных шаблонов
Выше я писал о недостатках покупных шаблонов. Пришло время вновь коснуться этой темы.
Нередко создатели сайтов городят костыль на костыле, чтобы получить «уникальный дизайн» путем переделке существующего шаблона. Это долгий и неудобный путь, чреватый к тому же рассаживанием ошибок в стилях и верстке. Куда более простым представляется сдизайнить элементарную html-ку на таблицах, прописать нужные позиции модулей и их исчезновение в случае неиспользования на конкретной странице и расписать css наиболее удобным способом.
Простой, удобный путь, позволяющий максимально подогнать сайт под потребности конкретной фирмы, скомбинировать сильные стороны html и cms-решений. Этот путь, однако, выбирают немногие.
По идее, можно сказать еще очень много о том, как делать не надо — и не меньше о том, как сделать хорошо.
Однако все равно суть сведется к трем корням ошибок, перечисленным выше — желанию выехать на готовом, нежелании учиться и читать мануалы, а так же фанатичном преклонении перед WYSIWYG-решениями, выражающемся в нежелании разбираться с кодом. Пока эти три кита не побеждены, нет смысла даже и думать о конкретных одиночных ошибках — ведь избежав одной, тут же сделаешь другую.
Dixi. Надеюсь, этот текст если и не сказал вам ничего нового, то, по крайней мере, натолкнул на мысли.
Так уж сложилось, что автору, рекламщику по основной специализации, в этом году подвалила нехитрая халтурка от знакомых — выправить косо сделанный на популярной CMS ресурс одного оффлайного магазина — и дать совет, как его развивать. Справившись с основной частью работы, я очень сильно задумался. Настолько сильно, что заинтересовался проблемой и посвятил ее изучению некоторое время. Создавалось впечатление, что многие ошибки, отталкивавшие посетителей — которые и ошибками в прямом смысле слова назвать сложно — являются не фирменным знаком горе-разработчика, а практически стандартом для современных российских ресурсов. То же можно было сказать и о многих ошибках настоящих, полновесных.
Серфинг по рунету, казалось, подтверждал странный вывод. Получалось, будто многие веб-разработчики не знают самих основ — от HTML и CSS до элементарной верстки. И сайты не «срабатывают» именно по этой причине. Предположение было странным.
Тем временем исправленный сайт начал давать стабильный приток клиентов (чего отродясь не делал), а новый сайт фирмы, созданный уже лично мной с учетом увиденного, поднял этот показатель еще в несколько раз… Компания перестала рассматривать интернет как «шашечки» и дала приличный бюджет на рекламу в Сети — к нашему обоюдному удовлетворению.
Для самообразования я продолжил копаться в теме и, кажется, нащупал корни основных ошибок многих создателей сайтов. Именно наличие этих корней и превращает сайты из инструмента бизнеса в строчку на визитке, тем самым портя репутацию всем, подвизавшимся на ниве работы с ними.
Должен предупредить — я не скажу ничего нового для профессионалов, однако, судя по увиденному в сети, многим продающим свои услуги в качестве «веб-разработчиков» не мешало бы это прочесть.
Поехали!
Для начала следует и осознать одну простую вещь — каждая деталь сайта важна. Быть может, никто осознанно не считает сколько пикселей в отступе картинки от текста — но даже такая, казалось бы, мелкая деталь влияет на общее впечатление от ресурса. А именно от него зависит, будет ли сайт эффективен.
Идеологическая ошибка номер ноль — или «veni-vidi-vici»
Никто не спорит, что использование CMS значительно упростило работу, особенно в случае, если на сайте присутствуют большие массивы информации. Однако живущая в людях надежду на халяву подкладывает неслабую свинью как разработчику сайта, так и его нанимателям.
Увы, слепая надежда на вариант «поставил-накатил шаблон-PROFIT» способна убить ресурс.
Как именно? Есть несколько вариантов.
1) Готовые шаблоны
Помните благословенные времена дайл-апа и порталов? Стоп. Вычеркните слово «порталы». Ему не место в одном предложении с эпитетом «благословенный». Каждый школьник, освоивший тег "" и сумевший открыть Frontpage ваял собственный портал, бессмысленный и беспощадный. Все они были сделаны по одному лекалу. Все использовали одни и те же куски кода. Кто-нибудь, кроме их создателей, посещал их? Вот-вот.
Нынешние времена мало отличаются от тех. Тысячи сайтов с одинаковыми шаблонами с одних и тех же сайтов-продавцов (или вообще торрентов), отличающиеся лишь мелкими деталями, логотипом, цветовой схемой и бэкграундом. Одинаковая организация подачи информации, одинаковые контейнеры… Да что тут говорить! Все это видели. Миллионы блогов на вордпрессе не могут ошибаться и все такое.
Напоминаю про правило пяти секунд на странице (ладно, может и не пяти, а восьми, к тому же есть разные варианты, но «пять секунд» звучит круче). За эти несчастные секунды пользователь решает, остаться ли ему на странице или свалить. Подумать над тем, как именно влияет стандартизованный дизайн (притом далеко не всегда отвечающий цели показать пользователю то, что ему надо) на отток посетителей оставляю читателю.
2) Сложные шаблоны
Эта проблема целиком и полностью вытекает из предыдущей. В попытках ее решить, не напрягаясь, продавцы сайтов идут на парадоксальный шаг — используют чужой сложный шаблон с обилием разнообразных свистелок.
Казалось бы — что тут такого? Слишком сложно — не слишком просто, задел на вырост, опять же. Однако чрезмерно сложный покупной шаблон способен добавить новых проблем. Особенно это характерно для Joomla, где простенький на вид шаблончик может разожраться на несколько «физических» шаблонов — каждый со своими css-файлами, конечно.
В возможном конфликте составляющих частей отредактированного «жирного» шаблона и кроется проблема. Не увиденный поломанный стиль может оттолкнуть пользователей — а заметить и выправить эту ошибку будет не так уж и просто. Да и сам сайт кое-где может начать подглючивать.
К тому же сложные шаблоны в той же джумле плохо переносят обновления системы.
3) Расширения, много и разные.
Чем больше расширений от сторонних разработчиков — тем веселее. В теории. На практике хорошей идеей будет проверять их на совместимость со всеми основными компонентами сайта и друг с другом.
Действует тот же принцип, что и в прошлом пункте — даже самая малая ошибка будет замечена пользователем и сыграет не в пользу владельца сайта. Увы, это действительно так работает. В то же время — чем более сложна система, тем больше вероятность, что где-то она засбоит.
4) Пиратский софт
Упомянутые проблемы и сами по себе не слишком приятны. Но сделать их гарантированно непереносимыми способно использование пиратских версий. На трекерах полно ворованных шаблонов, расширений и так далее.
Пользоваться подобным, конечно, давняя традиция, но, право же, подумайте сами — вы не писали этих инструментов. Их разработчики — люди. И, выпуская коммерческий продукт, они волей-неволей рассчитывают на возможность патчем поправить какую-либо неисправность. Поскольку CMS и их компоненты, по идее, должны регулярно обновляться, любое обновление системы способно сломать ворованные вами куски кода. Оно вам надо?
5) Выбор инструмента. А нужна ли CMS?
Конечно, если на сайте ведется постоянная работа с большим количеством контента, без CMS не обойтись. Но если ваша задача — сайт-визитка без десятков галерей и новостных лент, куда более логичным представляется использовать старый добрый HTML. Цээмски активно пытаются хакнуть боты. Написание полноценного шаблона отнимает время — и к тому же, если необходимо создать сайт на пять не обновляемых страниц, быстрее получится работать с HTML — ведь вы не будете ограничены необходимостью написания шаблонов, настройки модулей етс. Следовательно, при прочих равных HTML, возможно, окажется удобней.
Зачем использовать микроскоп вместо кувалды — и наоборот?
Идеологическая ошибка номер раз — или «ignorance is bliss»
Обычное невежество не улучшает ситуации.
1) Незнание стандартов
Возможно, для кого-то это будет новостью, но на ранжирование сайтов поисковиками, влияет, в том числе, влияет и соответствие различным стандартам — как W3C, так и общепринятым стандартам структуры веб-страниц. Например, отсутствие h1 на страницах скажется отнюдь не позитивно. Зачем портить положение сайта в выдаче?
2) Незнание HTML
Пара лишних тегов title на странице тоже ситуации не улучшит.
3) Незнание CSS
Да, никто не будет под микроскопом разглядывать количество пикселей в маржине. Но впаивать взаимно конфликтующие стили, надеясь на «авось» — глупо. Глупее разве что считать, что структура построения материалов на сайте всегда будет единообразной — и потому не предусмотреть возможности легко и просто настроить стили в конкретном месте под требования момента, а жестко задать их в основном css. Различные прилипания картинок к краям контейнеров, смещения центровки… все это, столь часто встречающееся, растет из этого.
4) Незнание основ дизайна
Понятное дело, от разработчика сайта всегда хотят всего, побольше и желательно вчера. Однако наивно полагать, что даже отличные навыки в коде заменят дизайнера. Более того — хороший дизайн не есть красивый дизайн. Это дизайн, выполняющий свою работу. Дело в том, что у любого сайта есть своя задача. И дизайн служит ее выполнению не в меньшей степени, чем что-либо иное.
Именно от дизайна зависит, поймет ли пользователь, что нашел «то самое» за те несчастные секунды, что проведет на странице, решая, смотреть сайт дальше или закрывать вкладку.
Если у вас нет приличных навыков в дизайне (да даже если и есть!) хорошей идеей перед разработкой вариантов для заказчика будет просмотр западных сайтов аналогичных тематик/назначения. Кое-какие решения вполне можно творчески позаимствовать.
5) Любовь к стенам текста
Запомните, в интернете никто не читает. По крайней мере, если не имеет заранее цели прочитать что-то (именно поэтому вы сейчас читаете эту строку, и то не факт, потому что искать картинки мне влом). Стену текста можно скормить пользователю только когда он полностью уверится, что он там, где надо. Картинки в этом способны очень даже помочь.
Идеологическая ошибка номер два — или «страх убивает разум»
Самый любопытный вывод, который я сделал для себя, изучая состояние сайтов «средней руки», а равно форумы пользователей CMS и прочих подвизавшихся на ниве разработки сайтов лиц — многие смертельно боятся лишний раз заглянуть в код. И это способно серьезно повредить облику сайта — а следовательно, и его эффективности.
1) Проверка валидности кода
Выше я писал об ошибках в html. Далеко не всегда их причина — незнание. Нередко неправильно настроенная CMS может дать аналогичную картину, сажая ошибки, теги с устаревшим синтаксисом етс.
Решить такие проблемы обычно просто, главное их обнаружить. Для этого достаточно посмотреть исходный код страниц сайта в браузере. Увы, многие этого не делают.
2) Исправление ошибок CMS
Нередко можно наблюдать различные баги в интерфейсе, обусловленные кривым кодом самой CMS. А как влияют проблемы с юзабилити на посетителей, всем, думаю, понятно. Как ни странно, во многих случаях вовсе не обязательно ждать патча. При минимальных познаниях и наличии инструментария (Firebug, например) эти проблемы можно решать самостоятельно.
Чтобы не быть голословным, приведу пример — Joomla (по моей версии — вообще самая глючная из популярных CMS) в версии 1.5 имела проблемы с компонентом блога, решаемые именно в коде. В версии 3.1.5 без использования напильника пользование админкой было несколько затруднено (например, при создании пункта меню невозможно было перелистывать страницы списка материалов, а только находить нужный поиском). И решалось все элементарно.
3) Создание собственных шаблонов
Выше я писал о недостатках покупных шаблонов. Пришло время вновь коснуться этой темы.
Нередко создатели сайтов городят костыль на костыле, чтобы получить «уникальный дизайн» путем переделке существующего шаблона. Это долгий и неудобный путь, чреватый к тому же рассаживанием ошибок в стилях и верстке. Куда более простым представляется сдизайнить элементарную html-ку на таблицах, прописать нужные позиции модулей и их исчезновение в случае неиспользования на конкретной странице и расписать css наиболее удобным способом.
Простой, удобный путь, позволяющий максимально подогнать сайт под потребности конкретной фирмы, скомбинировать сильные стороны html и cms-решений. Этот путь, однако, выбирают немногие.
Итог
По идее, можно сказать еще очень много о том, как делать не надо — и не меньше о том, как сделать хорошо.
Однако все равно суть сведется к трем корням ошибок, перечисленным выше — желанию выехать на готовом, нежелании учиться и читать мануалы, а так же фанатичном преклонении перед WYSIWYG-решениями, выражающемся в нежелании разбираться с кодом. Пока эти три кита не побеждены, нет смысла даже и думать о конкретных одиночных ошибках — ведь избежав одной, тут же сделаешь другую.
Dixi. Надеюсь, этот текст если и не сказал вам ничего нового, то, по крайней мере, натолкнул на мысли.