Обсуждение вообще вышло довольно примечательным; я, кажется, с чрезмерными претензиями к личным качествам и профессиональным навыкам специалиста, из которого получается хороший верстальщик, а ребята в комментариях только подчёркивали это; Женя Бондарев писал:

дизайнер верстающий должен обладать логическим мышлением, изрядным аналитическим складом ума, мыслить не образами, а логическими конструкциями
именно. при этом человек, обладающий именно таким складом ума, скорее станет программистом и будет получать гораздо более адекватные деньги, чем верстальщик. вы же не дадите верстальщику ставку программиста?
…
Надо сравнивать зарплаты сопоставимых по уровню квалификации специалистов.
А в этом сравнении, верстальщик практически всегда будет в проигрыше.

В какой-то степени Женя прав, даже с меркантильной точки зрения в нашей компании (где программеров в любом случае раз в 5 больше, чем дизайнеров) хороший (а значит, как минимум ведущий) программист будет получать больше хорошего верстальщика, но здесь вот ещё в чём сложность расчётов: на больших проектах задачи распределяются на подзадачи и направления, и кроме PM`а на проекте есть несколько подкоманд программистов, каждой из которых управляет ведущий программист, лучший. Т.е. он не только лучше всех программирует, он ещё занимается менеджерской работой, распределяет задачи внутри своей команды и отвечает за качество кода своих подзадач. Это всё-таки другая ответственность. К сожалению, всегда бывает так (это я по себе знаю), что большую часть задач, которые ставятся перед командой, ведущий специалист может выполнить сам, и, более того, быстрее, лучше, качественнее (и дальновиднее, потому что умеет видеть проект в целом и перспективу), но задач в какой-то момент становится несколько… больше, чем может выполнять один человек за один рабочий день, а клонировать этого самого ведущего программиста пока технологии не позволяют.

Что же касается сравнения зарплат у обычных программеров и у верстальщиков, то здесь всё очень даже сопоставимо, а с ростом команды, когда и в нашей, дизайнерской команде понадобится выделять тимлидеров и некоторым ребятам добавится административной работы, то зарплаты будут становится сопоставимыми с зарплатами ведущих программистов, я в это верю. Но есть здесь и другой момент, о котором стоит говорить. У меня много примеров, когда человечек приходит в веб разработку, как верстальщик (веб-дизайнер), начинает изучать js, потом – серверное программирование и… в чисто вёрстку уже не возвращается. И не знаю случаев, когда программист начинает серьёзно интересоваться html+css, бросает своё программерство и становится верстальщиком. И дело не только в деньгах, во многих причинах, в том числе и в том, что “есть устойчивое мнение”, что статус программиста в любой IT компании, в любом IT сообществе выше, чем у верстальщика.

Нашла недавно старую уже шутку по теме, “Памятка верстальщику, мнение программера” – мило для тех, кто умеет посмеяться над собой и несовершенством мира, но если говорить серьёзно, то есть проблема с подобным отношением к верстальщикам. Мы тут на прошлой неделе заспорили с одним из программеров по поводу одного визуального глюка и методов его решения, вот он мне что-то типа такого и выдал, что “я здесь программер, и я решаю, какая будет логика на этом участке!” – пол часа бессмысленных препирательств закончились тем, что тимлид по этому проекту нашёл время подойти к нам и выяснить в чём проблема, выслушать обе стороны и подтвердить, что МОЁ решение — верное, а программер просто в собственном коде чего-то недосмотрел. И таких ситуаций в нашей компании было довольно много, видимо, поэтому ребята, которые не новички и работают со мной больше двух лет, спорят редко и уж тем более не смотрят свысока, а зачастую даже спрашивают совета по более концептуальным вопросам, чем “как отформатировать этот блок”. Но для того, чтобы на сегодняшний день было ТАК, нужно, чтобы во многих предыдущих спорных или сомнительных ситуациях верстальщик ОКАЗЫВАЛСЯ ПРАВ, и его статус рос с каждым верным решением.

А для этого нужны знания и опыт, потому и желательно “и творческое, и аналитическое мышление”, и — умение в сложной ситуации взять на себя ответственность, и умение мотивировать свои решения, объяснять как команде в целом, так и каждому отдельно взятому программисту, как бы свысока он поначалу не смотрел. Когда к тебе кидается программист с обвинениями в твоей кривой вёрстке и говорит, что вот он “взял тобой отвёрстанный блок, вставил его в новый документ, прописал в документе ссылку на твою же таблицу стилей, и эта таблица стилей работает не полностью, криво, где-то что-то не центрируется, где-то ещё какие-то глюки выползают”, и достаточно одной минуты на анализ проблемы: ага, программер создал документ, умничка, и код правильно скопировал, и ссылку правильно поставил. Только при генерации этого нового документа забыл указать Doctype, вообще. Подумаешь, одна непонятная такому гениальному программисту строчка.

Уметь отстаивать качество своего кода, в котором уверен, а то недавно наш канадский гений, который принимает нашу вёрстку веб-сайтов и занимается интеграцией в общую систему, громко (мы-то не слышали, но канадское руководство аж письмо спешно написала о том, что вот, мол, Алан кричит, что вы опять плохую вёрстку выложили) обвинял в некоторых, гм, некроссбраузерных записях в таблице стилей и требовал, чтобы поля и отступы описывались четырьмя значениями (верх-право-низ-лево) даже для симметричных свойств, типа margin: 2px auto; – это недопустимо и глючит в разных браузерах, надо писать margin: 2px auto 2px auto;, когда же я задала ему вопрос о том, что это проверялось точно ли с указанным Doctype? И если да, можно ли мне дать пример, где и для какого браузера сокращённая запись НЕ РАБОТАЕТ? он написал, что вот прямо так сразу под рукой этого примера нет, но “будет время, он продемонстрирует”, и вот вторую неделю ищет примеры, и канадское руководство, так же, как и мы, ждёт подтверждения, справедливы ли были обвинения этого интегратора в том, что украинская вёрстка – безграмотная.

Кстати и Женя Бондарев, который своим комментарием заставил задуматься о специальностях, пограничных с вёрсткой – программер, и проблему поиска хорошего верстальщика, а так же отношения к вёрстке и программированию видит со своей программерской точки зрения.

А вот Zigzag видит специалиста с другой стороны:

Да, тяжело найти первоклассного вебтехнолога, как нас, верстальщиков, сейчас называют. =) Но я всеравно против дизайнера и верстальщика в одном лице. Вот UI Designer и верстальщик совсем другое дело, часто UI дизайнеры из верстальщиков рождаются.

Я Паше ответила, что это, видимо, потому, что верстальщик понимает не только то, как форма или окно должны выглядеть с точки зрения “удобства пользования”, но и с точки зрения логики самой формы, сценариев отображения форм, да и с точки зрения реализации тоже.
Программеры смотрят на интерфейс изнутри. Менеджмент, юзеры – снаружи. А верстальщики…
Вообще, это другое видение экранного интерфейса, когда у тебя долгое время практика смотреть на него (интерфейс) изнутри и снаружи одновременно. Верстать, проверять, тестировать, да ещё и когда у тебя 14 из 16 контейнеров с формами скрыты и показываются в зависимости от разных условий, и эти сценарии тоже нужно в голове держать, и не только код делать оптимальным, но и пытаться оценивать оптимальность самих сценариев, и, конечно же, на совещаниях (митингах) не молчать, высказывать мнение о том, как оптимизировать экраны, упростить формы, сократить шаги сценариев. А как же ж без этого? Т.е. специальность проектировщика интерфейсов — она на самом деле так же близка к верстальщику, как и программирование.

В заключение я бы хотела попиарить один случайно обнаруженный конкурс (проводится при поддержке Ru-Center) для веб-разработчиков… который, вообще-то, объявлен уже давным давно, ещё в апреле этого года, видимо, в своё время я проигнорировала информацию. Обратила внимание на знакомое имя среди организаторов: автор идеи и председатель оргкомитета конкурса WebHiTech — Артемий Ломов. Когда-то я регулярно читала его колонку о веб-дизайне “Веб-анатомия по воскресеньям“, была подписана на его рассылку. После, пару лет назад, приятно удивлена тем, что Артемий, решив завязать с рассылкой на Subscribe.ru, передал подписчиков моей, на то время регулярно выходившей рассылке “Библиотека Сайтостроительства…“, мда.. ностальгия. Да, так вот. Помимо интересной самой по себе идее конкурса обратила внимание на миссию конкурса:

Миссия конкурса WebHiTech — посильное содействие повышению культуры веб-разработки в Рунете посредством популяризации уважительного отношения веб-разработчиков к духу (первостепенно) и букве (не первостепенно, но тоже важно) актуальных рекомендаций Консорциума W3C. Имеются в виду, главным образом, спецификации расширяемого языка разметки гипертекста XHTML 1.0 Strict и XHTML 1.1, каскадных листов стилей CSS2 и руководящие указания по обеспечению доступности веб-контента WCAG 1.0.

Помимо прочего, в правилах конкурса обнаружено:

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

• Страницы сайта оформлены в духе разумного, функционального минимализма, производят безусловно позитивное эстетическое впечатление и воспринимаются как завершенные и целостные композиции.
• Все страницы сайта оформлены в едином стиле. Сайт создает целостное впечатление.
• Страницы сайта рационально используют площадь окна браузера. Оргкомитет конкурса отстаивает убеждение, что «резиновая» верстка при прочих равных условиях предпочтительнее фиксированной по ширине.
• Область основного содержания использует максимально возможную (без ущерба для других функциональных областей) площадь на пространстве страниц. Безусловное предпочтение отдается сайтам, на которых нет бесполезных для посетителей элементов, таких, как нетематическая реклама и т. д.
• Система навигации сайта интуитивно понятна, информативна и всячески способствует экономии времени и сил посетителей. Ссылка, ведущая на текущую страницу, считается грубейшим недочетом. Наличие полнотекстового поиска по всему контенту сайта приветствуется.
• Посетитель может легко изменить размер шрифта на странице штатными средствами привычного ему браузера (даже если речь идет об IE).
• Текстовое содержание сайта, а также альтернативные текстовые комментарии к графическим изображениям и другим объектам, являющимся частью контента, полностью доступны пользователям консольных и речевых браузеров, устаревших версий графических браузеров, пользователям, привыкшим отключать графику.
• Важная для пользователей функциональность всех сервисов сайта сохраняется при отключенных JavaScript, Flash, ActiveX и т. д. в браузере.
• HTML-разметка отвечает исключительно за логическое структурирование контента, тогда как управление его представлением (внешним видом, особенностями воспроизведения программами синтеза речи и т. п.) полностью возложено на CSS. Предпочтительно использование внешних листов стилей, загрузка которых не требуется с каждой вновь открываемой страницей.
• HTML-код страниц соответствует идеалам семантической верстки. (Заголовки размечены тегами <h1>…</h6> в соответствии с естественной иерархией, но никак не <font>; абзацы — тегом <p>, но не <br>, таблицы используются только по прямому назначению и т. п.)
• Контент сайта легко индексируется поисковыми машинами, переход поискового робота между страницами сайта не затруднен никакими технологическими ограничениями (например, навигацией, реализованной на основе JavaScript).
• На сайте предусмотрены автоматически генерируемые, прозрачные для пользователя (т. е. не требующие от него никаких действий) версии представления контента для вывода страниц на печать и для просмотра их на экранах карманных компьютеров.
• Страницы сайта отображаются без существенных различий во всех сколько-либо распространенных на текущий момент графических браузерах: IE 6—7, Opera 8—9, Firefox 1—3, Safari 3.
• Код разметки обнаруживает полное соответствие спецификации XHTML 1.0 Strict (менее желательно — HTML 4.01 Strict) или XHTML 1.1. Код листов стилей полностью соответствует спецификации CSS2.
• Текст на страницах сайта вселяет уверенность, что его автор (редактор) в совершенстве владеет русским языком и правилами набора.
• Иллюстративная графика и фотоматериалы, размещенные на сайте, не вызывают сомнений в художественных талантах и технических навыках их авторов.
• Любая страница сайта загружается не более 10 секунд даже в том случае, если для доступа в Интернет посетителем используется модемное соединение со скоростью 28 800 бит/с.

Оргкомитет отдает себе отчет, что идеальных информационных сайтов, как это ни печально, не существует в природе, однако полагает, что вышеприведенная «контрольная карта» сможет стать неплохим подспорьем для потенциальных участников конкурса на этапе принятия решения о целесообразности выдвижения того или иного проекта.

Я, с одной стороны, пиарю конкурс и рекомендую веб-мастерам подавать заявки, а с другой — обратить внимание на эту “контрольную карту”, которая (почему нет?) вполне может стать прототипом списка для самопроверки веб-разработчика и для тестирования специалиста на очередном собеседовании. Раз уж мы в поиске такой… творческой личности с аналитическим складом ума, ха-ха.

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

У нас команда большая, проекты (те, которые с web интерфейсами) есть не очень большие, а есть крупные сервисы, а есть и просто ветка рекламных сайтов (коих на каждый разрабатываемый продукт несколько делается, то на разную целевую аудиторию разные, то под разные задачи), где разделение на “дизайнер рисующий”+”дизайнер верстающий” просто уместно с любой точки зрения, хотя бы даже с целью оптимизации процесса. Канадское руководство, кстати говоря, дотошно пытало меня,  довольно долго, зачем же нужно подобное разделение? Я долго пыталась объяснить и с одной точки зрения, и с другой, и в конце концов сформулировалось что-то типа такого “всё-таки дизайнер рисующий — личность особо творческая, с развитым образным восприятием мира, способный создавать визуальные формы с нуля, типа креатив, а дизайнер верстающий должен обладать логическим мышлением, изрядным аналитическим складом ума, мыслить не образами, а логическими конструкциями”.

Причём и я, и вы, уважаемые читатели, мы все хорошо знаем, что да, бывает такое, что в одном человеке одинаково хорошо сочетается и творческая личность, и аналитик, состоящий весь из логических цепочек и иерархических структур. Но редко, господа, редко, и найти такого человека для работы в своей команде — это ещё ой как повезти должно, такого специалиста холят и лелеят, такую встречу нужно перед миром какими-то особыми заслугами в прошлой жизни заслужить, видимо. Найти человека, для которого достаточно будет минимальных знаний графических редакторов и с не атрофированным напрочь чувством вкуса и меры, знающего основы вёрстки всё-таки проще, теоретически. На практике же и с этим какие-то хронические проблемы. Может, не зря Антон сказал, что и не слышал о такой специализации – “верстальщик”, и в самом деле в нашем городе их нет (а есть такие вот на все руки псевдомастера, которые рисуют посредственные сайты и завёрстывают их посредственным кодом), и я себе придумала миф, в который только я и верю? Ага, иногда так и кажется.

Кстати к теме, уж не знаю, как мировое сообщество переводит на английский язык слово “верстальщик” (причём для web, а не для полиграфии), но у наших канадских партнёров в ходу слово “интергратор” – это как раз тот чувак, который берёт нарисованный для него эскиз и создаёт из него рабочий сайт. Интергирует, так сказать, визуальный прототип в реальный проект. И они там, и мы здесь (я и моя маленькая команда верстальщиков) — страшно сказать, интерграторы. Однако как только речь заходит о крупных .NET`овских проектах, они тушуются… вот был период, когда на одном крупном сервисе был период небольшого перепроектирования и редизайна, который совпал с перетрясками административными, и тогда канадская команда было сказала, что редизайн (и связанную с ним ре-вёрстку) они будут делать сами. И ладно, мы не обиделись, баба с возу… Прошло время. Срочное совещание по громкой связи с нами и срочно – два дизайнера-верстальщика на этот проект. Потому что… их “интерграторы” налажались и не справились. Потому что их верстальщик открыл .aspx и сказал, что он здесь ничего не понимает. Потому что даже в шаблонах он напортачил так, что я потом ещё долго чистила за ним безобразные, недопустимые на больших проектах конструкции.

Вспоминаю, как я, несколько лет назад, пришла в нашу контору и наш Технический Директор тоже меня… собеседовал. Собственно, смешно вспоминать начало диалога, я всё равно на тот момент знала о вёрстке на порядки больше, чем он, однако главное, что его интересовало — смогу ли я работать с движками, написанными на .NET, понимаю ли я код, который (он мне показывает) вот в этом, .aspx файле? Что я могла ответить. У меня вообще не было практики сотрудничества с .NET программерами, ни единого проекта. Однако было изрядно .php и (меньше) .java, и я самоуверенно заявила на собеседовании: нет большой разницы делать вёрстку под любую платформу, если есть понимание закономерностей, которые таки прослеживаются во внутренней логике любой из них. И я была права! Даже при том, что мне всё-же пришлось обучаться “на лету”, не было ни одной задачи, ни одного контрола, студийного или стороннего, который бы я не смогла приструнить под заданный стиль проекта.

И вот второй год поиска верстальщика, готового справляться на должном уровне с нашими задачами меня не то, чтобы расстраивает, но как-то, признаюсь, настораживает. Практика показывает, что очень не всегда расчёт на то, что “обучим здесь, по ходу дела” срабатывает, что есть изрядная инертность и зловредные “ложные истины”, которые тормозят специалиста в саморазвитии с одной стороны, и мешают командной работе над *успешным* проектом с другой. Потому что то, что допустимо (или, во всяком случае, не критично) в сегменте разработки 5-10 страничных сайтов-презентаций, не позволительно на серьёзных проектах. А привычка допускать кривости – она остаётся, она живёт в верстальщике и отражается в каждом первом проекте, и не надо строить иллюзий, что “в этом” проекте он, пусть с ним, юзает вложенные таблицы и атрибуты для визуальных стилей, а вот “в этом”, строгом, сделает стерильно. Не сделает.

Может, я себя не так веду на собеседованиях? Ставлю не те задачи, спрашиваю не о том? Сегодня вот ещё будут два человечка, девочка и мальчик. Оба позиционируют себя именно как технические дизайнеры, для вёрстки и, немножечко, для js, что нормально. Ссылки на сайты в их портфолио не впечатлили, код в лучших традициях конца прошлого века (прочем, и в то время были ребята, которые писали здравый код), и что я? Опять спрашивать о том, что такое Doctype и для чего он нужен? Как имитировать кнопку ссылкой свойствами css или позиционировать вот такую вот модель? А как же узнать, способен ли человек думать и анализировать проект, с которым ему придётся работать? Угадывая наперёд, где какое наследование будет уместно, где понадобится динамика или шаблонизация при росте проекта, чтобы на каком-то этапе не споткнуться о собственные костыли, когда без концептуальной перевёрстки проект становится ущербным и дико избыточной вёрсткой и страшной таблицей стилей? Не замыкаясь на ограниченной задаче “отверстать вот эту, присланную утром картинку” лишь бы отображалось похоже и гордиться этим, громко споря и заявляя – не важно, что там внутри и как оно написано, главное, что отображается похоже и кроссбраузерно, и валидацию даже сайты Артемия Лебедева не проходят, и лучший валидатор — браузер! Эх, икается, наверное, господину Лебедеву, кумиру юных, нуждающихся в авторитете, подражающих даже в ошибках…

Я тоже не сразу нашла. Честно говоря танцы с бубном пришлось исполнить. Знаете, что оказалось? Их мудрый верстальщик, или кто-то там, кто правил ресурсные файлы, открывал xml на редактирование в каком-то (пока не знаю в каком) редакторе, который после себя оставил некоторое количество непечатных символов, не в смысле матерных, а в смысле не отображаемых. Они не обнаруживались простыми методами, они не показывались в исходном коде документа браузера, они не ловились даже если с клавиатуры по символам идти построчно. Совершенно случайно в M$ Studio в режиме редактирования полей ресурсов увидела странные квадратики. Почистила код, запустила проект ура, всё работает! Заодно обнаружила ещё несколько кривостей, уже не наших. Отписываю это всё канадскому PM`у:

Alex: так-перетак-разтак!!! Как ты смогла это вычислить?
Tatyana: гы. танцы с бубном
Alex: шаман, однако
Alex: Ты можешь все это кинуть мне в мыло? Подробненько, чтобы и дятлу было понятно. Пли-и-из
Tatyana: Счас, секунду. только я по русски напишу письмо
Alex: Да хоть на суахили. Мне все-равно туда нужно будет маты вставлять
Alex: Ну открой секрет, как же ты все-таки находишь такие баги, Таня
Tatyana: Я ковыряла долго. Потом, с возрастом приходит убеждение, что чудес не бывает
Alex: А-а-а-а, так вот в чем разница. Я-то все еще верю в чудеса…
Tatyana: Чудеса может и бывают, но логически предсказуемые!

1. Если легко придумывается адекватный текст для alt, то нужно делать картинкой
2. картинки фоном в CSS — это крайняя мера, потому что “обнаруживать их в CSS – это не прозрачно”
3. когда стили отключены, кнопка должна отображаться как кнопка
4. представить, что все img на странице проиндексируются поисковиками и будут выдаваться в поиске по картинкам. Иногда помогает сориентироваться, где уместно использовать тег img /, а где – фончик в css.

На самом деле вопросов, связанных с логикой и семантикой вёрстки возникает много и не все они решаемы (или легко решаемы), где-то знаний не хватает, где-то хорошие тенденции рубятся “корпоративной политикой” или просто выбором технологий. Там же, в комментах к тому же посту несколько раз попросили дать ссылки на некоторые наши проекты, я уже как-то писала и ещё раз напишу: извиняйте, ребятки, не дам. Но задумалась о том, что вовсе не на всех наших проектах такое пристрастное требование верстать дивами, да ещё и обращать внимание на логику кода и семантические тонкости.

Действительно, если сложилось впечатление, что мы тут эти… фанаты исключительно дивной вёрстки, то оно правильное только отчасти. А потому, что удовлетворять пристрастие к правильному коду получается на сегодняшний день только для части проектов, для рекламных сайтов (которых много, не скрою), небольших проектов из конечного количества страниц и с заведомо известной структурой, предварительно (и гарантированно) утверждённой ДО НАЧАЛА ВЁРСТКИ. Но не все проекты у нас такие везучие. Как только речь заходит о не однотипных рекламных сайтах, а, к примеру, о каких-то сервисах-тулзах, то просто не получается. Прежде всего потому, что как правило утверждённого проекта на наши сервисы-тулзы мы не имеем, разработка происходит по накопительной модели.

К примеру разрабатывается каркас сервиса, с какой-то базовой функциональностью. Для того, чтобы презентовать его учредителям компании и/или инвесторам, его надо визуально “причесать”. Придумывается какой-нибудь дизайн, отвёрстывается макет, тюнится движок, на этом этапе вёрстка, как правило, ещё приличная, т.е. без костылей и практически всегда – без хаков. Дальше (в случае если) после презентации проект начинает бурно развиваться, разными программерами, работа верстальщика – подтюнить то, что напрограммировали программеры, в рамках же существующего дизайна. И вот здесь начинаются грабли, которые заканчиваются тем, что через пару месяцев на когда-то стерильный код просто страшно смотреть: костыли на костылях, сплошные хаки для хоть какой-то кроссбраузерности, вылазят такие требования к “элементам оформления”, которые в концепцию изначальной сетки просто не помещаются. Да, и таблицы. Мы как будто бы умеем верстать довольно сложные макеты без таблиц, но не тогда, когда невозможно предсказать требований к макету через день или уж тем более через месяц. Да, запускаем табличный каркас под основную модульную сетку (ну почти всегда). И здесь единственное решение – затребовать время на полную перевёрстку проекта. Написать с нуля, описать по-другому модульную сетку, продуманно и грамотно, сделать совершенно другие цепочки наследований свойств, убираются здоровенные избыточные конструкции, которые при изначальной модели и убрать-то нельзя, много всего посыпется. Но это не столько от безграмотно построенной первоначальной модели html+css, сколько от того, что со временем изменяется сама концепция. Кто-то может сказать, что это уже к вопросу проджект менеджмента, мол, должно же быть какое-то ТЗ, в рамках которого разработчики ваяют свои шедевры. Здесь я вижу две проблемные стороны:

1. Да, основное – это организационная проблема, когда всё ТЗ состоит из рекомендаций и пожеланий, которые просто добавляются по ходу разработки, когда продуманные изначально, скажем 5 разделов через пару месяцев дорастают до 10 и уже не вписываются в разработанную изначально модульную сетку, когда сама архитектура проекта меняется несколько раз принципиально и не только “а давайте добавим ещё парочку разделов в главную навигацию”, и “а почему бы быстро не сделать мультиязычность” (правда ведь никого не волнует, что в изначальном макете не особо было предусмотрена такая беда и, в частности, то, что количество букв в названиях, скажем, элементов меню на английском, немецком и французском иногда ну о-о-очень сильно разнится), когда каждый тим лидер в рамках озвученных пожеланий сам себе аналитик, когда спустя пол года проект уже ничем – ни визуально, ни по функциональности не напоминает тот сентябрьский, который презентовался в первой версии.

2. С другой стороны обычное дело в современных условиях разработки: всегда всё нужно сразу, всегда всё должно быть интуитивно понятно и без написанного плана проекта, стартап заявляет о себе базовой функциональностью, и уже после того, как становится интересен аудитории (а значит и инвесторы найдутся без особых проблем) внимает всем пожеланиям пользователей и расширяет свою функциональность, так сказать, по ходу дела. И здесь с одной стороны никому не интересны капризы верстальщиков, у которых на глазах разваливается продуманная для первой версии проекта модель – нужно быстрее, нужно сразу, нужно бежать, бежать в два раза быстрее хотя бы для того, что бы остаться на рынке. Здесь единственное разумное решение – дождаться того, что на каком-то этапе гонка закончится хотя бы незначительной паузой и руководство выделит человеко-часы на редизайн и ревёрстку всего проекта с нуля.

По второму пункту – да, вот прямо сейчас именно этим мы и занялись по одному из наших сервисов. Который начинался с двух простеньких контролов, работающих с простенькой базой данных. Там тоже была головная боль с тем, что заказчик точно не знал, чего же ему на самом деле хочется, но получив ту самую базовую функциональность, начал хотеть всё больше и больше, а сделать это было реально, добавлялись разделы, тулзовые панели, отчёты и фильтры, многопользовательский доступ и прочие пряники. Изначальная вёрстка, такая стерильная, логичная, семантичная, была забыта усложнившейся нереально модульной сеткой, таблица стилей выросла до кучи файлов с кучей же избыточных описаний и кривых наследований, но скоро, уже скоро всё изменится. Проект почти год крутился у клиента в том самом, более-менее законченном состоянии, работающий и внешне опрятный, но на вёрстку и стили я без содрогания смотреть уже не могла. И вот клиент созрел на полный редизайн, функциональность, кажется, меняться, во всяком случае принципиально и в ближайшее время не будет. Сделаем конфетку

Так что по поводу холиворов на тему табличной и дивной вёрстки – да, мы ищем лёгих путей и как только у нас начинается очередное “стремительное развитие”, идём на компромиссы, таблицы используем и для каркасов и для оформления сложных форм, на более-менее предсказуемых же макетах в табличной вёрстке просто нет необходимости. Когда мы верстаем сайты, которые без дотнетовских движков, безтабличной вёрсткой ещё можно похвастаться, но как только речь заходит о дотнетовских проектах, то вопрос становится неактуальным, потому что кто в теме, тот и без меня знает, что такое дотнетовские контролы типа гридов или листвьювов, календарей или прочих “продвинутых” решений и во что они рендерятся в браузере. Ага, правильно! Таблицы в таблицах в таблицах. Т.е. полюбому приходится в таблицах стилей описывать элементы модульной сетки, построенные на табличной вёрстке. Это реальность, от которой никуда не денешься, разве только что если сменить компанию, где в качестве базовой технологии разработки используется что-нибудь другое.

Ну и на последок – примеры-частности. Ага, визуальные редакторы контента веб-страниц. Сделали замечательный такой сервис для мини-социальной сети (там закрытая группа, мало кому будет интересно), отличненько. По ТЗ мы делаем только каркас (топ, навигация, панель с тулзами), а содержание информационных страниц создают редакторы сервиса. Поставили им для начала простенький редактор – цвет текста поменять, картинку вставить, абзацы-ссылки-списки, конечно же, режим редактирования без визуальных средств чистый html, что людям нужно ещё для полного счастья? Им нужен продвинутый визуальный редактор типа как у word`а! Некоторое время пробовали уговорить, объясняли, какой бардак сейчас начнётся, не объяснили. Они захотели вот этот со всеми включенными тулбарами.

Разумеется уже через неделю раздались крики по поводу того, что у них на всех страницах (кроме главной), где они добавили своё содержание, разъехалось ВСЁ. Захожу в проект, смотрю, что они там намудрили, и не понимаю – зачем им весь этот расширенный тулбар, если они всё равно в визуальную зону вставляют форматированное нечто из того же word`а? Где у них образовалась таблица в таблице фиксированной ширины на 1500 пикселей и куча вторичного чиста word`овского кода в тегах? Предложили им простое решение – в контейнере, куда они грузят свой контент, добавить описание класса что-то типа overflow:auto;, не-а, говорят, не подходит. Не красиво. Полосы прокрутки не предусмотрены в концепте. Написали им документаху – чем можно пользоваться, чем нельзя и куда смотреть если что. Не помогло опять. Просто с какой-то периодичностью приходится заходить к ним с админскими правами и чистить тот код, который они очередной раз вставили в качестве обновлённого контента своих страниц.

Вот ещё замечательный пример: на ярушке один из верстальщиков глубокоуважаемого Яндекса Вадим Макишвили запостил провокационный пост про таблицы в макетах:

Не существует сейчас надежнее средства для создания сложной раскладки, чем таблица. Под надежностью я понимаю:
- уверенность в правильном поведении раскладки
- уверенность, что последующая модификация раскладки не принесет часов геморроя
- скорость разработки раскладки
Плюйтесь в меня желчью, фанаты семантики. Плюйтесь-плюйтесь… Когда вам доверят верстать портальные морды, которые обложены главным требованием — “ничего никогда не должно сломаться” — вернётесь к раскладе таблицами.

На сегодняшний день 139 комментариев, некоторые не безинтересно почитать; в частности, о резиновых каркасах, о различных ограничениях по ширине (Виталий Харисов: “В данном конкретном случае возможно. Не задавай max-width вообще. Если ты дебил и разворачиваешь окно браузера на максимум на 30″ мониторе, то тебе ничего не поможет.“) и о том, кто должен продумывать тот или иной тип макета и поведение блоков на странице.

Предыстория такая. Наши украинские дизайнеры (типа младшая группа) рисовала много эскизов “в туда”, часть из них проходила, и мы делали по этим эскизам небольшие сайты. При старом арт-директоре были, конечно, расстраивающие недопонимания, плохо была налажена обратная связь, переписка в основном состояла в том, что я ему писала “дайте же наконец хоть какие-то комментарии”, в мессенджере пинала, мол прочти письмо и ответь, получала ответ, что ASAP, и всё, дальше молчание. К вёрстке у нас каких-то конкретных требований не было, кроме как бы и так понятных – валидный HTML, валидный CSS, никаких табличных макетов (это, кстати, по поводу дискуссии про то, что лучше, это другие могут выбирать то или другое или даже дискутировать, а у нас, помимо идеологии и принципов, так было заявлено в ТЗ), по возможности текст делать текстом (ну, если уж совсем декоративные заголовки, то хидерами-подменками с длинными координатами).

Причём все эти месяцы я слышала (и получала известиями в мессенджере) информацию о том, что нам будут высланы какие-то технические требования к макетам, которые мы должны соблюдать. Я периодически напоминала, получала ответ о том, что “да-да, готовится”, а потом первого арт директора уволили и взяли второго, с которым мы общаемся уже скоро месяц как (третью неделю, вроде, или четвёртую). И всё по-новой: мы готовим вам документ с техническими требованиями к верстаемым сайтам, и этот документ будет выслан ASAP. Как в, разумные мои читатели, и сами понимаете, этот документ уважаемые наши заатлантические партнёры так и не прислали, и я даже сомневаюсь в том, что они его досочиняли, и вообще у них в голове есть какая-то типизированная схема, по которой эти требования можно составить.

Бр-р-р опять много букв на вступление, а теперь вопросы:

1. В коротком письме, отосланном (вчера вечером по их канадскому времени или сегодня ночью по нашему) этим вторым арт-директором, было отчаянное требование ОСТАВЛЯТЬ В ОТПРАВЛЯЕМЫХ ОБРАТНО .PSD ДОКУМЕНТАХ СЛАЙСЫ. Опс. Какие слайсы? Это в том смысле, что наши верстальщики не должны были учиться вменяемой вёрстке, а должны были тупо резать скетчи в Image Ready? Вот здесь вопрос. Может я чего-то не знаю про слайсы и удобные инструменты для автопорезки? Последний Image Ready – может, я про него чего-то не знаю? Насколько мне известно, даже в самом настроенном случае, в самом правильном этот красавец генерит либо (очень аккуратную) табличную вёрстку (с RollOver`ами, с готовым скриптом) или же CSS разметку макета с абсолютным позиционированием. Т.е. если его и пользовать как-то, то, получается, только для быстрой порезки фоновых картинок. Может, и правда имеется ввиду быстрая нарезка фончиков, но вдруг нет, вдруг есть какие-то продвинутые инструменты для работы со слайсами? А я отстала от жизни со своей недешёвой ручной работой?

2. Второе письмо зацепило ещё больше. Содержало обиду на то, что этот самый второй арт-директор жалуется на вёрстку в одном из последних сайтов, якобы на то, что кнопка “Download Now почему-то оказалась бэкграундом“. Ну понятно, что по аналогии с предыдущими макетами “Download Now” – это не кнопка, а ссылка (a href), и ведёт она куда надо, и стоит правильно, а вот то, что она такая красненькая декоративная – да, картинка и в самом деле подгружается в таблице стилей для класса ссылки. Потому что фончик у этой ссылки-псевдокнопки – это элемент декора, а не функциональный объект, и вполне логично вынести картинку для фончика в css. Я же так понимаю, что наш этот (второй) арт-директор искал в хрефе именно img src=”" mce_src=”", т.е. объект-картинку, расположенную в объекте-ссылке, которая ведёт на страницу Download. Т.е. в его картине мира такая модель является правильной, а реализованная нами – не верной настолько, что он ПЕРЕВЁРСТЫВАЛ! Ну ладно, я не против, но уж если мы говорим о качественной профессиональной вёрстке, то каким-то образом нужно выяснить, какое решение будет правильным. И почему (по словам нашего партнёра) арт-директор был возмущён нашим решением? Т.е. не просто отметил, как альтернативное, но по каким-то причинам не подходящее, а именно ВОЗМУТИЛСЯ и пожаловался начальству на качество кода украинских верстальщиков?Причём мы-то как раз не против, ежели это есть часть конкретных технических требований (которое мы, как я выше писала, не получали и на словах даже не обсуждали), трудности я не вижу никакой (более того, вообще не понятна проблема с “перевёрстыванием”, посмотрела я последний код, если уж так понадобился в вёрстке тег img, то в его src просто вставляется тот же адрес, который в пути к фону в классе для ссылки, там же всё ясно). Но так ли уж правомерен упрёк именно в недостаточной качественности кода? Это довольно принципиальный вопрос, потому что больше всего в партнёрстве на сегодняшний день расстраивает именно грузилово с упрёками в непрофессионализме — и тут же доступ к работам канадских “профессионалов”, от “качества” которого мы просто теряемся. Как в случае скетчей (у нас “не проходят” очень неплохие работы, очень, но тут же присылаются на вёрстку скетчи, отрисованные канадскими дизайнерами, и мы тихо млеем: совершенно отвратительные скетчи в стиле 90-х годов прошлого века у хомпейджей на narod.ru выглядели зачастую пристойнее, а вёрстка – это просто песня, и я писала уже о качестве ихней вёрстки даже в этом блоге). У нас разное понимание того, что такое качество, и что такое профессиональная вёрстка, это уже ясно. Единственный способ – преодолеть на сегодняшнем митинге (собрание по громкой связи по телефону с их гоп-компанией) желание рассвирепеть и поругаться и попытаться, как бы это выразиться… обсудить конструктивно, обменяться технологическими процессами и знаниями для взаимной пользы и выработать (с обоих сторон) новые правила и критерии качества.

Нет, но пример с псевдокнопкой всё равно следует обсудить здесь, для начала.

Было приятно увидеть людей, которых как будто знала, с которыми как будто была знакома, поздороваться, поговорить. Выпадение из рутины офисного процесса происходило тяжело – я непривычна к командировкам и поездкам, чувствовала себя не особо уверенно в незнакомой обстановке, человек по натуре не компанейский, на большой тусовке хоть и пыталась не прятаться, но подойти ко всем, кто был интересен, постеснялась. Ну и ладно.

Мероприятие, как и было обещано, прошло в конференц залах (двух) Президент Отеля (публика периодически перетекала из одного зала в другой за интересными докладами), всё было так солидно и по взрослому. В холле бар и столы для кофебрейков. Вайфай работал стабильно, но с моего htc что-то куда-то писать было лениво. Зато появился повод лишний раз задуматься о том, что разработчики интерфейсов веб-сайтов, особенно всяких редакторских интерфейсов типа админки вёрдпресса, могли бы серьёзнее подойти к вопросу юзабельности и доступности блин этих самых интерфейсов для мобильных устройств.
Спешно перед поездкой, в самый день отъезда, купила мыльницу – выбор в пользу малых размеров, потому что возиться с любимым Canon`ом (который Canon EOS 400D Kit 18-55) тяжко, да и в условиях прогрессирующей лени бессмысленно. Но для мыльницы не взяла зарядное устройство для акка, и к вечеру первого дня она благополучно разрядилась, так что фотки будут, но позже и не очень много.

Долгожданные доклады о правильной вёрстке были отслушаны, всё понравилось, всё правильно, но чуда не произошло, ничего такого, чего бы я не знала или не использовала, никаких, гм., откровений, ессно, не прозвучало. С другой стороны, доклады по XSL оказались сложнее, чем мне понятно, будем догоняться реальной практикой на местечковых проектах.

UPD второй день: на следующий день то ли я адаптировалась, то ли список докладов (и докладчиков) сложился удачный, но второй день показался более плодотворным и ярким. Понравились доклады по интерфейсам новостийных сайтов, по методам тестирования юзабилити веб-интерфейсов, познакомилась и обменялась контактами с Геннадием Осипенко, Юлией Климентовской, Полом Гокиным (Paul Gokin), надеюсь, с пользой. Некоторые докладчики впечатлили – хорошим, уверенным знанием темы, которую читали, умением общаться с аудиторией, способностью увлечь даже такой темой, к которой я, к примеру, прямого отношения не имею (но имею опосредованное отношение). Один пример – доклад Марины Дидковской “Тестирование и оценка времени”. Я с нашими тестировщиками общаюсь напрямую, и, хоть они формально не являются моими подчинёнными, зачастую приходится тратить изрядно времени на введение людей в тему, на объяснение деталей процессов, особенно на тестовых версиях проектов, объяснения, кому какие баги надо постить и почему какой-нибудь “этот визуальный баг” таковым не является и прочие житейские радости.

Хотелось бы, конечно, подробнее пройтись по всем докладам, но так получилось, что я ничего не конспектировала, изданные тезисы восстанавливают в паммяти не все доклады, а записываемые ролики, к сожалению, будут доступны не раньше, чем через 2 недели, а может, и позже. Потому что, как сказали организаторы, ролики ещё надо оцифровать, порезать и разметить, а это время, и вообще… Может, после поездки наберусь сил, о чём-то напишу подробнее.
Ну и, конечно же, благодарности организаторам. Юра, ты умничка! Такое грандиозное мероприятие организовать… Олегу Бунину и Павлу Рогожину. Всем киевским и московским организаторам. И докладчикам – не поленились напрячься, подготовиться, выступить. И участникам – приехали, собрались, значит, не зря суета была. Спасибо Наташе и Лёше Колупаевым за приют
В общем, не жалею

UPD2: а что делать с этой красивой карточкой profyclub`а? Вот этот роскошный номер – его куда-нибудь нужно вбить?
Интересно, что на РИТ я регестрировалась ещё в прошлый раз, увы, не поехала, и не поеду на этот. Надо бы и поработать. С другой стороны, хотелось бы быть в теме, хотелось бы получить материалы конфы, да не спустя год, а как бы сразу. Если будет прямая трансляция – так же узнать где вовремя, а не на следующий день пялиться на “прямой эфир остановлен”, да.

Помните, были в недавние ещё времена споры о том, кто такой веб-мастер и что входит в его обязанности? В дискуссиях определились, что веб-мастер – это такой и швец и жнец на все руки мастер, который в небольшой компании и за сервер в ответе, и за общую работоспособность корпоративного сайта, и письма из обратной связи принимает, и для их приёма почту настраивает, и контент обновляет если что. Но может ли быть такое в большой компании, где есть системный администратор, и не один, где есть DBA и тоже не один, где штат саппорта больше сотни человек, а контентщики не имеют вообще никакого отношения к веб-дизайнерам – их обязанности разделены и чётко формализованы? С дизайнерами в маленьких компаниях похожая ситуация – одному человеку в обязанности вменяется и скетчи для веба нарисовать, и сайт отверстать, и флеш на нём забабахать, и базу данных прикрутить, и визитки в полиграфию отправить, и предпечатную подготовку для всех бланков и презентаций компании провести.

В нашей компании какое-то количество лет был один дизайнер – он именно так и назывался (не будем показывать пальцем, хотя, разумеется, это была я) , и это, с позволения сказать, дизайнер рисовал скетчи на сайты, отвёрстывал как простые сайты, так и макеты под шаблоны движков, и стандартных, и нашими же программерами писанных, с дальнейшей адаптацией вёрстки для новых страниц наших развивающихся проектов, рисовал, собирал и тюнил скины для виндовз-приложений, создавал пиктограммы и полноформатные иконки для программ, с программерами же оптимизировал интерфейсы этих же виндовз-программ; а так же периодически вёл переговоры с заказчиками и принимал участие в постановке более-менее внятной задачи для разработчиков. Время идёт, всё меняется как бы к лучшему, теперь в компании есть целый отдел, где более узко заточенные специалисты занимаются всем тем же самым, но задачи для них распределены. Есть несколько рисующих дизайнеров – кто-то специализируется на скетчах для веб-интерфейсов, кто-то на миниграфике, иконках для программ и прочих “элементах” интерфейсов, есть несколько верстальщиков — у кого-то лучше получается собирать самодостаточные сайты (визитки, рекламные, без движка в основном или на стабильном, не дорабатывающемся ежедневно движке), кто-то неплохо освоился в наших дотнетовских проектах и больше верстает с (и за) программерами на новых текущих проектах. Так вот для нашего руководства — была я одна – меня называли дизайнером, а теперь весь наш отдел, всю нашу команду по инерции традиции тоже называют дизайнерами. Потому я так часто использую термины-разделители “дизайнер рисующий” и “дизайнер верстающий”.

При этом если поглубже копнуть в определение термина “дизайнер”, то противоречия здесь никакого нет. Я ведь не просто так последние месяцы писала о качественной вёрстке – да, считаю и приучаю наших верстальщиков, что “дизайн” в смысле “проектирование” имеет непосредственное отношение к их работе. Очень здорово, если ребята умеют анализировать отданный им в работу скетч, продумать оптимальную модульную сетку, спланировать базовый шаблон контейнеров – а не тупо резать скетч на слайсы, запихнув пару фонов в стили и там же в таблице стилей прописав три десятка классов для разного оформления шрифтов (вчера исправляли один из старых наших же проектов, где верстальщик именно так и поступил, а та самая стопка классов, при детальном анализе, была вообще избыточна). Проектирование своей будущей разметки – чем не дизайн?

Кроме того ещё одна особенность замечена (раньше как-то не особо обращала внимание). Если я в нашем корпблоге публикую (или в месенджер отсылаю ссылку на) какую-то сугубо техническую информацию – хаки или красивые решения для css, какие-то особенности стандартных (соответствующих спецификации), но не кроссбраузерных примеров и т.д. – это предназначается только верстальщикам, да и в блоге обсуждают только верстальщики. Если же публикую общедизайнерскую информацию – ссылки на удачные дизайнерские портфолио, интересные заметки о цвете или правильных интерфейсах – отсылаю всем, и рисующим, и верстающим. Что-то мне подсказывает, что развивать чувство прекрасного, чувство гармонии, знать основы композиции будет очень не лишним даже для таких технарей, как верстальщики. Это, конечно, так же к вопросу о не во всём хорошей организации работ в нашем офисе. К примеру, не редкие ситуации, когда проект присылается как бы уже отрисованный и даже отвёрстанный (это кошмар в большинстве случаев), и надо что-то там поправить-причесать, руководство при этом определяет работу как задачу для верстальщика и только; и по выделенным человеко-часам – тоже только верстальщик. Которому, может, и не запрещается обратиться к рисующим “за консультацией”, мол, какой лучше цвет для фончика хидера в этом гриде или достаточные ли отступы у элементов этой формы, но по большому счёту работает он один. Такие кривые задачи приходят не часто, но практика показывает, что заказчики и руководство считают, что здоровое чувство вкуса и здравый смысл – достаточно для того, чтобы верстальщик самостоятельно справился, написал таблицу стилей и доверстал код.

А сейчас появилась потребность в новом “дизайнерском” ответвлении, ещё одной специализации. Я даже не знаю как назвать такого специалиста, и понятия не имею как его тестировать… но об этом в следующем посте. Заканчивая эту тему, хочу сказать, что всё-таки формализация необходима и срочно, потому что часто бывает, что качели нагрузки то клонятся в сторону объёмов для рисующих дизайнеров, то в сторону объёмов для верстальщиков, а руководство, между прочим, оценивает работу отдела в целом и деталями интересоваться отказывается, и фраза “у вас там шесть человек, что, все так заняты? Почему медленно?” звучит не так уж и редко. Объясняться каждый раз, что верстальщик не будет рисовать этот ваш логотип или что рисующая девочка не может поправить поехавшую вёрстку в коде проекта – тяжело и обидно, и здесь уже я начинаю строго следовать формальным определениям, защищая своих красавцев. Но всё равно в глазах руководства наша команда – это отдел дизайнеров, чем бы мы там внутри команды не занимались и как бы не перераспределяли между собой обязанности, вот так вот.

В такой ситуации разработчики понимают, что если постараются, как просят, то в самом деле это и участие в чём-то глобальном/интересном, и полезный опыт, и повышения зарплаты, и на самом деле есть смысл поднапрячься (так было у нас с тем августовско-сентябрьским дедлайном, тяжёлым, но оправданным, как показала жизнь). Особенно, если сверхурочные оплачиваются и на предыдущих проектах разработчики убедились, что их не кинут, что это не гнусное использование рабской силы, а за хорошие проекты в самом деле надо бороться всей командой, сообща. Потому в прошлом у меня столько было заметок о командной работе, о взаимопонимании между группами разработчиков, между рисующими дизайнерами и верстающими, между верстальщиками и программерами, и между всеми ними и менеджерской надстройкой.

Но бывают и совсем другие дедлайны. Которые от безграмотного менеджмента и неуважения к разработчикам. Когда проект у людей висит уже не первый месяц, они что-то там возились, оптимизировали и даже разрабатывали функциональность, потом забрасывали на какое-то время, потом вдруг, скажем, под вечер в среду присылают письмо с архивом (!) проекта, частично даже без исходников (precompiledWeb), мол, ребята, вы там причешите в стиле (***) – в общем, нашего предыдущего большого проекта. Всё это без описания функциональности и без документации на сам проект, типа вы же такие умненькие, разберётесь. Типа, там же только таблицу стилей подредактировать. Запускаю проект (ага, без исходного кода, без связей, ещё повозиться надо, чтобы он вообще запустился, чтобы вообще хоть как-то увидеть интерфейс глазками, покликать по функциональным элементам), и тихо млею от того, насколько безграмотно организовано филе… больше сотни .aspx страниц, без шаблонов, с кошмарнейшим html кодом – доктайп не прописан ни в одной из, сплошные незакрытые или закрытые ошибочно теги (открыт параграф, закрыт спан), зато всё оформление прописано атрибутами в самих тегах. Да и значения атрибутов в одном теге то в двойных кавычках, то в одинарных, то совсем без оных. Встроенный в редактор валидатор кода зашкаливает, и это естественно – он подчёркивает всё, где видит неправильность, т.е. его использовать для правки смысла не имеет. А ещё часть функциональных элементов (сложных гридов, к примеру, с сортировками/фильтрами/настройками внутри, или календарик для фильтра по датам) вообще собираются js скриптом полностью – т.е. те же теги и атрибуты тегов – шрифты, цвета, фончики, извиняюсь. Какой css?? Ну и, повторюсь, весь этот хлам без сопроводительной документации. И даже тот факт, что запускающая для проекта страница называется Test.aspx, разработчики должны были понять сами ага.

Отписываютсь заатлантическим – ребята, тут недели на две кропотливой работы… А они мне… нет двух недель. У нас презентация в пятницу (помним, что проект пришёл в среду вечером). Вы уж там постарайтесь. Ну и как это называется? Это как раз и называется дедлайн безграмотный. А я так собиралась на следующий день отволынить от офисной работы вообще – планировала пойти на конфу по интернет-маркетингу… Я, кстати, там всё-таки побывала, целых три часа удалось выделить; правда только один доклад из тех, которые хотела послушать, застала. Остальные были либо до того, как я приехала, либо после трёх, когда я уже уехала на работу. Править этот срочный проект, до пятницы, до презентации. В ходе работы старалась не сильно злиться на тех разработчиков, которые сочиняли этот безграмотный код —я написала про незакрытые теги и кучу атрибутов в них, но ещё можно добавить 75% избыточного кода – бесполезных таблиц, вложенных друг в друга. Без них ничего не испортилось, зато можно уже было как-то заниматься “причёсыванием” интерфейса, но ведь даже на удаление всего этого избыточного кода тратилось время, большая часть времени.

Вспомнился недавний не очень лицеприятный коммент от читателя *ATimofeev* к одному из последних постов – “Почему увольняют дизайнеров?“:

Я, конечно, дико извиняюсь, но по моему, в большинстве случаев, какие-то завышенные и неоправданные требования предъявляются.
Про верстку вообще ни в какие ворота. *человек доказывал, что его вёрстка — супер, кроссбраузерная, а валидация* – про валидацию согласен, пусть меня заплюют, но во многом считаю ее не нужным мифом, который придумали верстальщики, а вот суперкроссбраузерность во многом качественный показатель, за который ругать или не учитывать как минимум странно.
*начинаю одного за качество кода отчитывать и заставлять перевёрстывать* – а какое качество должен иметь код? По моему самое главное – это чтобы везде и всегда работало как положено, без косяков, тогда пока результата не будет можно придираться. Или Вам принципиально, чтобы теги елочкой строили? )

Теги ёлочкой — это понты дешёвые, это можно и специальным тулзом перестроить, если есть желание. Хотя я не понимаю, почему нельзя сразу форматировать как-то вменяемо, чтобы парные теги (если они есть, потому что в присланном проекте местами даже ссылки не закрывались) можно было бы найти достаточно быстро, но это мелочи и не к ним придираюсь. Да, качественный код — это прежде всего работающий код, с этим не буду спорить. Но есть много примеров безграмотного кода, который В ОПРЕДЕЛЁННЫХ СИТУАЦИЯХ визуализирует страницу так, как требуется по заданию и В ОПРЕДЕЛЁННЫХ СИТУАЦИЯХ не сбивает функциональность сервиса, и на момент тестирования в самом деле жить не мешают. Но это не означает, что его можно не исправлять. И если сервис планируется дорабатывать и развивать, оформлять и презентовать, то говорить о том, что безграмотный код можно допустить в работу – не правильно. Да, разумеется, определив доменному диву положенный ему по стилю фончик и бордюрчик (выше написала, что постановка задачи по визуалу – сделать так, как на предыдущем проекте, типа новый сервис – небольшое ответвление его же), и сразу увидела, что фон уехал не туда, и нашла, где контейнеру нужно быть закрытым. Да, и так по всем незакрытым тегам. А ведь это можно было найти валидацией документов, и не списывать всё на временно кроссбраузерное отображение страниц. Да, поудаляла все атрибуты в тегах и вынесла всю отрисовку в css. Да, прошлась практически по всем страницам проекта, свела к минимуму (но не вычистила полностью) всю муть, прописала доктайпы, “причесала”. Да, опять по 12 часов трудотерапии. Но суть переработки была не в сложности задачи, а именно от безграмотного менеджмента + безграмотного кода, написанного, кстати, не программистом-разработчиком, а очень даже дизайнером-верстальщиком, который просто считает, что такой код – это то, что можно себе позволить (начальство проверяет в браузере, а не в редакторе, начальство к валидации не придирается).

Я могу понять верстальщиков, которые держатся за свой кривой код и не считают, что нужно что-то оптимизировать и вообще о чём-то думать. Ведь есть целая ниша веб-разработки, где это совсем не важно: это дорвеестроительство, это небольшие малобюджетные 5-страничные сайты-визитки для малого и среднего бизнеса, делающего свои первые шаги в сети. Это простенькие сайты, где жизненный цикл разработки – нарисовал, заверстал (пусть даже и безграмотно), вывесил. И всё. Нет развития, нет необходимости обращаться к коду для чего-бы то ни было – таких сайтов полно и в рунете, и везде. Их никто не будет доделывать – их проще убить и сделать заново ©. Но ведь совсем другая ситуация, когда верстальщика привлекают в большой интересный сервис, где не только валидация имеет значение. Где имеет значение логика макета. Где нужно планировать и оптимизировать макет. И хорошей вёрстке нужно учиться, на многих проектах, живых.

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

1. Компания меняет профиль деятельности. Абсолютно реальная ситуация – дизайнер по-началу был востребован, приходили какие-то заказы на разработку сайтов, но редко и малобюджетные. И тут люди вклиниваются в бизнес, который к дизайну отношение имеет весьма далёкое, бизнес прибыльный – силы всей команды уходят в другую отрасль, заниматься поиском заказов и проработкой малобюджетных клиентов уже никто не будет, и специалист становится балластом. Сначала это не явно заметно – просто работы поубавилось, потом ему объявляют, что, мол, лишний ты здесь, до свидания, дорогой.

2. В компании меняются требования к специализации дизайнера. Сложно объяснить, близкое к первому пункту. Дизайнер по-прежнему нужен, но – другой, а старый становится не нужен (умеет визитки, но не умеет бигборды/ или стенды, умеет веб-сайты, но не умеет флеш, умеет 2D и не знает 3D, а ждать, когда научится – некогда, по новой специализации человек нужен уже вчера).

3. Устаревший профи. “Не модность” – у дизайнера нет стремления следить за модными тенденциями, популярными решениями; есть опыт, есть знания, но как засел в стиле эскизов 90-х годов прошлого века так в этом стиле и продолжает “”творить. Ему говорят – не модно, не стильно, не популярно, но то, что модно сейчас, он подвергает критике (безвкусица, попса… а вот в наше время!…). Современные тенденции в веб-дизайне брезгливо оценивает стандартным комментарием “здесь нет дизайна”. Очень жалко, потому что динозавр когда-то был лучшим (или одним из), и у него учились, и знакомством с ним гордились, и в пример ставили, и если было на что посмотреть в тех же 90-начале 2000, то это именно его сайты, в те времена на таком крутом уровне единицы могли работать, но… времена изменились. Увольняют, чтобы заменить более прогрессивными молодыми кадрами.

4. Нет вкуса. Отдельная песня – дизайнер умудряется во всём, что делает (не так уж и плохо), привнести элементы безвкусицы – цветовые сочетания у него не играют, элементы – то громоздки, то мелочны, композиция в целом – гуляет. В принципе, если сидеть с ним над каждым эскизом и корректировать весь процесс (давай переподберём эти цвета, здесь изменим размер полей, здесь уменьшим логотип, здесь поменяем шрифт etc.) – работать можно, но если бы он обучался, развивал вкус – это одно дело, на нескольких первых эскизах поисправлять ошибки и дальше работать как с нормальным человеком, но когда на каждом следующем эскизе опять неудачные цветовые сочетания, опять не так стоит лого, опять бросается в глаза неопрятность в модульной сетке… Долго терпели, честно – жалко было сразу прощаться; всё-таки хорошее знание (и владение) инструментами, фотошоп назубок, отрисовка в векторе чего-то там; пытались пересадить на отрисовку элементов (иконочек, пиктограмочек), но увы – и здесь, не то. Распрощались, хоть и со слезами.

5. Нет понимания специфики работы. Опять же — хорошее владение тулзами, и со вкусом всё в порядке. Но – то ли полиграфическое прошлое неистребимо настолько, что человек не может мыслить формами с динамическими размерами, то ли человек просто рождён для другой работы, не знаю. Но за полтора месяца не получилось объяснить, что рисовать нужно не красивые модные открытки, а эскизы для веб-сайтов, где часть графических элементов – это объекты с какой-то функциональностью, часть – оформительская графика, которой придётся “тянуться” по какому-то направлению. На очередной “открытке” спрашиваю – и где, каким образом этот диагональный градиент должен тянуться, если размер изменится? Не понимает. Увы, тоже похоже на первый случай, отличие только в том, что человек осознанно пришёл работать в явно обозначенную отрасль дизайна; но считаться с техническими особенностями макетов так и не научился.

6. Очень креативный. Эх, даже неловко за нашу компанию. Но у нас в самом деле крайне редко возникают задачи сделать интерфейс чего-бы то ни было “не типичный”, совсем не похожий на популярные решения. А обычные макеты ему не давались – везде хотелось привнести что-то суперское, что-то очень оригинальное, отрисовать какой-то необычный элемент… на это тратилось время, в 3D, к примеру, что-то наваять великолепное, и с построением модульной сетки макета вроде было неплохо, и поля/воздух чувствовал без дополнительных указаний, и цвета у него всегда были… может и не совсем обычные, но уж точно гармонично подобраны, а в конечном итоге работы не принимались, именно за чрезмерную оригинальность (ой… а можно нам что-нибудь попроще? просто эскиз для простенького корпоративного или рекламного сайта?). По моей оценке ему бы идеально подошла работа в каком-нибудь печатном супермодном издании, haute couture, (но он-то утверждал, что хочет сайты делать?), ну или если совсем уж повезёт – не частые, но уместные для его талантов фрилансерские заказы. Пришлось уволить, с сожалением великим.

7. Технический дизайнер с очень образным мышлением. Человека не смогли присадить на качественную вёрстку, объяснить, почему и как макет перед вёрсткой необходимо анализировать, почему нужно продумывать порезку очень тщательно, чтобы избежать избыточности в коде, чтобы сформировать правильную структуру контейнеров “родитель”-”наследник”. Я извиняюсь, конечно, но порезка эскиза слайсами в ImageReady – это не работа верстальщика, поставить направляющие, назначить одним движением мышки слайсы и сгенерить html-код – это и секретарша может, в этом нет работы технического дизайнера. Кстати на нём и запретили использовать для порезки ImageReady – может, работу кому-то на каких-то проектах и упрощает, но понимания логики документа точно не даёт. Всё-таки, думается, верстальщиком (как и художником, поэтом, великим физиком-ядерщиком или Ломоносовым) надо родиться, должны быть какие-то врождённые качества, другое мышление, особое видение мира, особое понимание структур данных. Объяснить же, почему так верстать нельзя – не получилось, человек доказывал, что его вёрстка — супер, кроссбраузерная, а валидация – что валидация, вон сайты Артемия Лебедева тоже не проходят валидацию без ошибок, и что – и ничего… (причём здесь валидация? Валидатор можно, разумеется, использовать для тестирования ошибок, но ни один валидатор из существующих на сегодняшний день не выдаст в результатах “не логично” или “избыточно”).

8. Сильно шустрый. Общительный, востребованный, известный, ему бы на выданной работе сконцентрироваться, а смотришь – одновременно он и в аське, и в скайпе, и в gtalk`е, окна мелькают, а в фотошопе два холста запущено, на одном – явно рабочий проект, на втором – халтурный, говорю – фигня, мол, закрой халтуру, займись делом, ага, сейчас-сейчас, тут немножечко, а завтра – я тут приболел, голова болит (а голос – боевой и смешливый), и в аське целый день, и с каждого месяца дней 10 рабочих – у него голова болит, и понимаю, что дома остался “халтуру” дорисовать, и рабочих эскизов за месяц – чуть ли не на порядок меньше сделано, чем у остальных. Что тут поделаешь… Что, говорю, денег мало? Всех денег, говорю, не заработаешь. Ты, говорю, определяйся, ты либо туда, либо сюда, а вот туда-сюда не надо, это раздражает руководство. Никто тебя не гонит, но надо бы… работать, в офисе. А не можешь соскочить с фриланса – выходи из компании. Распрощались. Расстраивалась.

Вот так вспомнились из опыта последних нескольких лет разные причины увольнения из компании хороших, в общем-то, людей. Может, допишу ещё попозже. Сейчас на своих поглядываю – не проскакивают ли знакомые признаки? Когда начинаю одного за качество кода отчитывать и заставлять перевёрстывать, второго – за композицию и очередные неудачные цветосочетания, третьего – за спешность (за час туда-сюда отрисовал задачу, но – без души, но – не достаточно в деталях продумано, или в качестве не видно усердия, выложил рабочее, через минуту смотрю – опять своё что-то творит). Ну да ладно, мы справимся.