1. Верстка, аутсорсинг и технические задания
Верстка — относительно независимый этап веб-разработки и, к примеру, в маленьких веб-студиях часто — это первый кандидат на аутсорсинг в условиях ограниченных трудовых ресурсов.Так сложилось, что мне часто приходилось отдавать эту работу субподрядчикам и, несмотря на предполагаемую однозначность результата, иногда верстальщики меня очень удивляли. Причем чаще — в негативном смысле.
Чтобы сэкономить трудовые ресурсы штатных верстальщиков, недостаточно просто переложить эту работу на плечи первого приглянувшегося фрилансера. Все намного проще, если вы постоянно отдаете работу на аутсорсинг одним и тем же исполнителям — в процессе длительного сотрудничества всегда складывается какой-то негласный свод стандартов и требований, выполнение которых входит в привычку. Но если вы работаете с человеком впервые — самое хорошее портфолио и рекомендации не гарантируют получения нужного результата и более того — даже не предполагают, что исполнитель вообще вас правильно поймет. Потому нужны детальные технические задания по верстке.
И этот момент игнорируется. Часто это происходит из-за предположения, что трудозатраты на написание детального ТЗ в сумме со стоимостью аутсорсинга не окупаются сэкономленным временем штатного верстальщика. В конце концов, верстка — это ведь не так уж сложно — думает рядовой project менеджер. И, как правило, это действительно прокатывает, *хвала человеческому интеллекту*, профессиональные верстальщики в большинстве своем ограничивают буйство экспериментаторского духа и заранее знают, какие технические решения в верстке могут вызвать у заказчика геморрой не столь адский, чтобы забанить верстальщика, но все же исключающий радость и восхищение прекрасным html-макетом.
Тем не менее, вероятность факапов, как показывает практика, не столь мала, чтобы этим можно было пренебречь.
А основное заблуждение здесь в том, что детальное ТЗ — это сложно и трудоемко. Какие-то специфические требования к макету в любом случае приходится описывать, а вот на общие требования и рекомендации, как правило, забивают.
2. О, велика моя скорбь!
Я недавно получил макет, который менеджеры отдавали на аутсорсинг и просто не знал, смеяться мне или плакать. Если бы не мне предстояло интегрировать этот макет в систему шаблонов CMS, я бы наверно все-таки смеялся.Табличная верстка и стили, не вынесенные в CSS файл и стандартный дримвиверовский скрипт для подсветки кнопок даже не воспринимаются как недостатки после того ада, который я увидел. Все поля ввода были вставлены внутрь тегов label, засунутых в отдельные формы, причем при попытках как-то привести это в человеческий вид, вся верстка разваливалась. CSS классы имели кириллические названия, причем не осмысленные, а вида «.стиль1,.стиль2». Большинство элементов форм стилизировались каким-то мало известным и до ужаса кривым скриптом на jQuery, некоторые элементы имели одинаковые ID и между ними был JS код, оперирующий как раз этими элементами и получающий их по ID, и верх маразма — это применение в конце документа метода jQuery.сss чтобы задать стили, которые ну совсем ничто не мешало просто прописать в CSS файл. А еще хедер сайта вместе с кучей ссылок (шрифтом Tahoma и без сглаживания) был сделан одной картинкой, на которую наложены элементы MAP и AREA. Не буду больше травмировать вашу психику описанием фейлов в этом замечательном макете, т. к. было их там еще бессчетное количество.
В общем, поверьте, товарищи, это был ппц, который к тому же подкрался практически перед самым дедлайном.Происшествия такого вот характера побудили меня опубликовать список требований и рекомендаций, которые будут полезны как людям, отдающим макеты на html-верстку, так и собственно верстальщикам.
Вы можете переработать эти рекомендации и дополнить ними свое типовое ТЗ на верстку. Многие вещи из перечисленных вполне очевидны, но вы можете извлечь profit из того, что все они собраны в одном месте. Некоторые пункты (к примеру требования к поддержке браузерами или используемым скриптам) для разных контор специфичны, но я не буду далее писать расплывчатых фраз, чтобы этот списочек можно было легко скопипастить и заточить под свою специфику работы.
3. Требования и рекомендации
1. Кроссбраузерность
Сайт должен нормально работать в IE7+, FF3+, Opera9+, Safari4+, Chrome последней мажорной версии (или в зависимости от условий договора с клиентом и года, в котором вы читаете эту статью).
2. Всегда описывайте цвет фона для body даже если он белый.
3. Если используете CSS хаки, комментируйте, что это и для какого браузера, а лучше используйте css_browser_selector.js. Заботьтесь о верстальщиках, которым придется работать с этим макетом после вас.
4. Названия классов и id должны по смыслу соответствовать применению
например, header, menu, footer, news
5. Просьба разделять основные html блоки комментариями. Примерно так:
<!--—BEGIN FOOTER -->
<!--—END FOOTER -->
Это нужно для создания из сверстанного html макета шаблонов для CMS, после чего комментарии будут удаляться.
6. Не пренебрегать возможностью использовать GIF/PNG с 8-битным альфаканалом вместо PNG-24, где это возможно.
7. Все что можно сделать без Javascript, делать без него.
8. Если Javascript кода много — нужно его выносить в отдельный файл. Обработчики событий тоже лучше отделить и объявлять в отдельном файле.
9. Если это еще не оговорено с заказчиком, предварительно оговорить, какие JavaScript библиотеки вы планируете использовать при верстке макета, чтобы потом не оказалось, что при верстке использовался, к примеру, PrototypeJS, а заказчик планирует в обязательном порядке внедрять на сайт jQuery.
10. Для резиновых макетов обязательно должна быть задана минимальная и максимальная ширина.
11. Если в Т.З. не сказано другое, макет обязательно должен помещаться без горизонтальных скроллбаров в развернутое на весь экран окно браузера при горизонтальной составляющей разрешения экрана 1024px, а если позволяет размер макета, то и 800px.
12. В папке с изображениями не должно быть картинок, не использующихся в верстке. Если что-то исключили из верстки или переделали — не забывайте удалять уже ненужные картинки.
13. Для всех элементов, которые могут содержать текст различной длины, который должен быть вписан в одну строку (например, для кнопок или заголовков, если в дизайне не предусмотрено, что они могут занимать больше одной строки), обязательно задавайте CSS свойство white-space:nowrap.
14. CSS файл должен быть разбит с помощью строк с комментариями на блоки по функциональному назначению, например:
/* ___________1. Сброс CSS____________________*/
/* ___________2. Типовые элементы____________*/
/* _______________2.1. Залоговки______________*/
/* _______________2.2. Ссылки________________*/
/* _______________2.3. Элементы форм_________*/
/*___________3. HEADER (Шапка сайта) __________*/
/*___________4. FOOTER (Подвал )_______________*/
/*___________5. SIDEBAR (Справа)_______________*/
Как именно структурировть стили — вопрос немного холиварный, но главное — как-то это делать.
15. Если сдача верстки производится более чем одним этапом (например, верстальщик отправляет страницы по одной, или если ему возвращаются на доработку уже сверстанные страницы) и вы не используете систему контроля версий для верстки, исполнитель должен в обязательном порядке прикрепить файл с описанием изменений в макете примерно такого содержания:
- Добавил новые картинки в папку img,
- Картинки btnHome.jpg и btnFeedback.jpg уже не нужны, можно удалять
- Изменил html-код в секции файла anketa.html
- Добавил в конец файла main.css новые стили (начиная с .form_row и ниже).
16. Оговорить, в какой кодировке должен быть html-макет. CSS и JS файлы должны быть в той же кодировке, что и макет, иначе вероятность долгой и утомительной охоты на баги критически возрастает.
17. Если в макете присутствует JS, изменяющий DOM — внимательно следить, чтобы все корректно работало в Опере, т. к. этот замечательный браузер при нажатии на кнопочку назад страницу не перезагружает, а отдает закешированный документ, причем очень важный момент: документ не просто закешированный, а еще и с учетом всех модификаций DOM, которые были выполнены с помощью JS
18. Не забывайте прописывать cursor:pointer для кнопок, сделанных не с помощью input. Если вы не знаете, будет на эту кнопку повешен обработчик событий с помощью JS или это будет ссылкой, лучше в любом случае использовать тег <a>.
19. Если вы делаете обработку событий при нажатии на ссылки, следите за тем, чтобы обработчики событий возвращали false, или же используйте href='javascript:void(0)' вместо популярного href='#', чтобы страница не скроллилась вверх.
20. Верстайте формы правильно: метки полей должны находиться в тегах label, имеющих правильно заполненный атрибут for. Предусматривайте при верстке форм элементы для вывода ошибок валидации и стили для неправильно заполненных полей. Если это не предусмотрено в т.з. и дизайне, обязательно обсудите это с заказчиком.
21. Если в макете используются нестандартные шрифты, обязательно оговорите, можно ли элементы с нестандартным шрифтом делать картинками, если нельзя — обсудите, с помощью какой технологии будет реализовано их отображение (sIfr, Cufon, etc.)
22. Если не оговорено обратное для частных случаев, все блоки, высоту которых ничего в дизайне не мешает сделать динамической, должны иметь именно динамическую (т. е. зависимую от содержания) высоту, а иногда, чтобы ничего не могло потенциально поломать дизайн, нужно задавать и минимальную высоту. Если хотите сделать блок фиксированной высоты — сначала спросите у заказчика.
23. В макетах, где высота страницы зависит от контента (а таких, как правило, большинство), предусматривайте, чтобы футер был прибит к низу браузера при отсутствии/малом количестве контента, если не оговорено обратное.
24. Если макет не проходит 100%-ную html-валидацию, постарайтесь по крайней мере делать так, чтобы использование невалидного кода было оправданно. Не стоит факапить валидность верстки т��лько потому, что «мне так нравится» или «так получается короче»
P.S.
Надеюсь, этот списочек требований и рекомендаций будет вам полезен! Если есть конструктивные мысли, предлагайте в комментариях, чем его можно дополнить.
