Сайт, готовый к редизайну и поддержке

Мало создать красивый сайт. Очень важно чтобы поддержка и редизайн происходили с минимумом затрат.

Советы как снизить издержки на редизайн и внесение изменений

  • Во-первых необходима CMS, чтобы отделить дизайн сайта от его контента. Это очевидно. HTML-сетка должна быть отделена от кода контента.
  • Никаких таблиц для нетабличных данных. Колонки — это ещё не таблицы. Конечно, существуют сетки, которые невозможно сделать без таблиц (из-за отсталости ie). Но таковых мало, просите дизайнеров не делать такие дизайны, укажите как можно упростить дизайн чтобы обойтись без таблиц. За последний год мне встречался только один дизайн, который нельзя было бы сделать без таблиц.
  • Задавайте классы по смыслу элемента, а не по его внешнему виду. Например, .important, а не .red. При редизайне цвет может стать совсем не красным, а синим, например.
  • Не используйте в контенте несемантические теги типа <font>, <center> и т.д. «deprecated». То есть теги определяющие внешний вид содержимого, а не смысл.
  • Не используйте инлайновый css (грыжа html). Потому как, от того, что описано пунктом выше это не отличается практически ничем. Затем при редизайне сайта вам придется выискивать все вхождения подобных конструкций. Замучаетесь. Поэтому только классы css.
  • Весь контент должен иметь семантический html-код. При возможности не используйте классов для стандартных элементов контента (маркерованные списки, заголовки, и т.п.), это удобно — не нужно править код wysiwyg-редактора.
  • Делайте валидный html-код сетки. Валидатор в последствии позволит вам быстро находить места где не закрыт какой-либо тег и оперативно это исправлять. Например, заказчик вам жалуется, что на такой-то странице в таком-то браузере всё падает, прогоняете страницу через валидатор, ага ошибка — не закрыты кавычки у ссылки, или не закрыт див. Это просто удобно и сэкономит вам массу времени и нервов.

Это просто рекомендую

  • Пользуйтесь режимом соответствия стандартам. Браузеров, которые его не поддерживают на сегодняшний день уже нет. Это позволит уменьшить количество затрат и головной боли на создание кроссбраузерного кода. А также добавит свободы действий с кодом.
  • Проверяйте как выглядит сайт, когда в браузере отключены картинки и отсутствуют стили. Доступны ли основные функции интеракивности при отключенных скриптах в браузере.
  • Выносите стили для ie в отдельный файл, подключаемый через условные комментарии. Потому как, некоторые браузеры могут входить в ступор при виде хаков для ie. Вплоть до полного игнорирования стилей, следующих за хаком.
  • Стремитесь к простоте и изяществу кода.

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

Виды редизайна (возможны промежуточные вариации):

Смена цветовой гаммы

Встречается довольно часто, обычно при смене корпоративных цветов. Наиболее простой и менее затратный вариант редизайна. Обычно дизайнеры берут готовый psd-макет, меняют цветовую гамму. html-код, содержимое сайта и функционал остаются без изменений. Верстальщик меняет картинки и правит немного css-файл на предмет новых цветов. При использовании специализированных приложений, таких как firebug и photoshop — это тривиальная задача. Дизайн: 20-50%, Верстка: 30-50%, Интеграция: 0%, Программирование: 0%, Наполнение: 0%.

Смена основного шаблона и цветовой гаммы

Наиболее частый вариант редизайна. Дизайн: 100%, Верстка: 70%-100%, Интеграция: 30-70%, Программирование: 0%, Наполнение: 0%. При правильном подходе наполнение 0, поскольку вам не нужно трогать контент чтобы изменить его внешний вид на всем сайте (достаточно правки css). А если сайт огромный, например, как сайт крупного сотового оператора, в десятки тысяч страниц, то это очень существенно.

Смена дизайна и переработка содержимого

Тоже что и в предыдущем пункте, только дополняются затраты на наполнение: от 0 до 100%.

Кардинальная переработка дизайна, содержимого и функционала

Тоже довольно частый вариант редизайна. Здесь всё зависит в какой фирме вы делали сайт, а в какой заказываете редизайн. Если в той же, то cms (и возможно часть модулей) менять не придется — на этом можно сэкономить. Этот вариант по стоимости практически эквивалентен заказу нового сайта. Дизайн: 100%, Верстка: 100%, Интеграция: 50-100%, Программирование: 50-100%, Наполнение: 50-100%.

Дополнение нового функционала

При правильном подходе затраты только на дизайн, верстку, интеграцию и программирование именно этих новых модулей. Всё остальное, что есть, не трогается.

Александр
25 января
Вы выписали почти все мои мысли. Молодцы. По больше бы таких статей на NOINIMOD :)
Дмитрий
28 января
Ребята, про сотового оператора это шутка была или вы всерьез так думаете, как написано?
Про инлайновые стили - тоже?
Дима Фитискин
28 января
Ребята, про сотового оператора это шутка была или вы всерьез так думаете, как написано?

Нет не шутка. Просто закралось некоторое недопонимание. Редизайн в реальности почти всегда затрагивает и модульную сетку, и функции, и навигацию. И провести его без правки HTML нам еще ни разу не удалось. Но вопрос о каком HTML идет речь.
99% HTML кода на сайте — это сверстанный контент. Все остальное - это 2-3 шаблона страниц и штук 10 шаблонов сервисов (новости, фотогаллерея и прочее). Так вот затраты на переверстку HTML кода контента (таблицы, формы, врезки и т.д.) на несколько порядков привышает затраты на то чтобы выкинуть старые шаблоны страниц и модулей и сделать новые. И это только потому что контента на сайте всегда больше. Цель этой статьи — обратить внимание на те проблемы, с которыми мы столкнулись при редизайне МТС в и , а также при .

Про инлайновые стили - тоже?

По моему все очевидные и неочивидные плюсы перекрываеются тем, что потом их фактически невозможно контролировать. CSS файлы к примеру можно сложить в одной папке — и они всегда под рукой. А с инлайн стилями как быть, RegExp`ом по всему контенту их выискивать? В любом случае мы стараемся обходится без использования инлайн CSS при разработке проектов.
Владимир
29 января
Не используйте инлайновый css (грыжа html).

Не использовать при создании разметки или при занесении текстового содержимого?

При возможности не используйте классов для стандартных элементов контента (маркерованные списки, заголовки, и т.п.), это удобно — не нужно править код wysiwyg-редактора.

По мне, так стандартные элементы, должны выглядеть как стандартные (простите за тафтологию).
Дима Фитискин
29 января
Не использовать инлайновый css при создании разметки или при занесении текстового содержимого?

Мы стараемся обходится без него и в том и в другом случае.

По мне, так стандартные элементы, должны выглядеть как стандартные (простите за тафтологию).

Стандартный элемент маркированного списка имеет кружек в качестве маркера. Если по дизайну предусмотрено другое — то на мой взгляд лучше переопределить меркер для ul li чем делать специальный класс для этого случая.
Дмитрий
29 января
Дим, при работе с объемными сайтами подходы вообще разные (). И соотношение шаблонов к контенту тоже разное, бывает и 60%/40%. А если элементы контента не удается хорошо структурировать по типу (врезки, вкладки, сноски), то остается выбирать:
  1. Либо все же унифицировать части контента, приводя их к единому стилю, но в ущерб читаемости/восприятия.
  2. Либо использовать inline-стили. Пусть не "по росту", но зато информация на каждой странице представлена самм читаемым образом.
  3. Либо вносить это все во внешние CSS, но есть риск упереться либо в раздутый вес файла, либо в технологические ограничения CMS (подключение нужных CSS на нужных страницах).

29 января

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

По моему мнению, 99.9% контента сайта можно унифицировать.

Либо вносить это все во внешние CSS, но есть риск упереться либо в раздутый вес файла

Никогда не сталкивался чтобы такие вещи значительно увеличивали размер css-файла. Экономия 10-20кб имхо не имеет смысла. Ведь CSS-файл грузится браузером один раз, и в дальнейшем берётся из кеша.

Дмитрий
30 января
надо смотреть, точно ли не будет подобного внешнего вида в других местах на сайте.

Существующий контент — да, согласен. А что делать с контентом, который "из будущего"? Например, на сайте Microsoft очень много разнородной информации есть и постоянно появляется. Если нет отточенного всестороннего грамотного гайдлайна (как у Apple, например), то веб-мастера работают в режиме freestyle.

Экономия 10-20кб имхо не имеет смысла.

Я привел ссылку выше: суммарный объем стилей — 120 кб. Есть над чем задуматься.
Имхо: лучше находить компромиссы, потому что крайности часто экономически не выгодны. Твой подход хорошо применим к сегменту, в котором вы делаете проекты, но для других типов сайтов он легко может не сработать.
Я разговор-то завел к тому, что на самом деле написание html - это максимум 20-30% всей работы по верстке (все остальное — CSS и нарезка) и не стоит привязываться к html при расчете экономии.

Дисклеймер: я целиком поддерживаю стандарты и сам являюсь приверженцем W3C.
Дима Фитискин
30 января
Твой подход хорошо применим к сегменту, в котором вы делаете проекты, но для других типов сайтов он легко может не сработать.

Согласен. Но если дать веб-мастеру сайта работать в режиме freestyle да при этом еще позволить не отделять содержимое от оформления (использование инлайн CSS никак иначе не могу назвать) — переверстать такой сайт будет по трудозатаратам все равно что сверстать его с нуля, плюс переверстать все материалы.
Если же весь CSS только во внешних файлах (пока не важна организация) — то часть CSS файлов можно поправить даже без просмотра страниц где он используется, остальные переверстать на примере одной.
А в случае если есть гайдлайн — можно сказать типовой случай для наших проектов (базовый задается при дизайне, в дальнейшем может расширяться), то тут редизайн можно сделать без правки контента вообще.

Представьтесь:

Электронная почта:

Текст комментария: