А ещё сегодня день рождения у замечательной miu-mau (может, вы ещё не читали её “Дневник дизайнера-маньяка“? зря!), и я поздравляю именинницу.

UPD2: Пока писала-публиковала про яндекс.субботник, пришёл спам про семинар-тренинг, причём бесплатный… но какой-то дурацкий. В том смысле, что вроде как честное и интересное мероприятие, но, во-первых, письмо не адресной с явно спамерской техникой присланное, во-вторых с неполной какой-то информацией:

Корпорация Oracle – крупнейший производитель корпоративного программного обеспечения и мировой лидер в области систем управления базами данных (СУБД) – приглашает Вас принять участие в семинаре “День разработчика Oracle 2009 в Санкт-Петербурге”.
Семинар будет проводиться 10 апреля 2009 года в ### отеле “Новотель Санкт-Петербург Центр” по адресу: ул. Маяковского 3а / Невский пр.

“День разработчика Oracle 2009 в Санкт-Петербурге” будет интересен широкому кругу специалистов, занимающихся разработкой программных продуктов, архитекторов и руководителей проектов, заинтересованных в использовании современных технологий и инструментов для создания программного обеспечения. Мы приглашаем к участию как специалистов компаний-разработчиков программного обеспечения так и специалистов групп разработки конечного пользователя. Ограничений нет!

Основная часть тренинга – практическая. Никакого лишнего “маркетинга” и “рекламной воды” – только необходимые для работы знания. Семинар проходит в классе, каждый участник работает на компьютере, подготовленном для тренинга.

Основное время уделено практике. Цель тренинга – предоставить возможность освоить методологию разработки приложений для СУБД Oracle Database и получить практические навыки по использованию новых возможностей программных продуктов Oracle.
-получить навыки использования новых возможностей Oracle Database 11g
-освоить методы быстрой разработки приложений для СУБД Oracle Database 11g
-получить практический опыт разработки простых приложений, используя Oracle Application Express 3.2 (ApEx)
-ознакомиться с архитектурой Oracle  Application Server 10gR3
-получить практический опыт разработки простых приложений, используя JDeveloper 11g и ADF (Application Development Framework)
-ознакомиться с новыми возможностями для разработки “.NET” приложений для СУБД Oracle Database 11g

ТРЕБОВАНИЯ К УРОВНЮ УЧАСТНИКА:
-опыт разработки приложений для СУБД Oracle Database
-базовые знания программирования на PL/SQL и Java

Участие в мероприятии БЕСПЛАТНОЕ!
РЕГИСТРАЦИЯ
Предварительная регистрация на мероприятие является обязательной!

Вы также можете зарегистрироваться по телефону в
Санкт-Петербурге: +7 (495) ### 795 2282

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

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

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

В какой-то степени Женя прав, даже с меркантильной точки зрения в нашей компании (где программеров в любом случае раз в 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 или позиционировать вот такую вот модель? А как же узнать, способен ли человек думать и анализировать проект, с которым ему придётся работать? Угадывая наперёд, где какое наследование будет уместно, где понадобится динамика или шаблонизация при росте проекта, чтобы на каком-то этапе не споткнуться о собственные костыли, когда без концептуальной перевёрстки проект становится ущербным и дико избыточной вёрсткой и страшной таблицей стилей? Не замыкаясь на ограниченной задаче “отверстать вот эту, присланную утром картинку” лишь бы отображалось похоже и гордиться этим, громко споря и заявляя – не важно, что там внутри и как оно написано, главное, что отображается похоже и кроссбраузерно, и валидацию даже сайты Артемия Лебедева не проходят, и лучший валидатор — браузер! Эх, икается, наверное, господину Лебедеву, кумиру юных, нуждающихся в авторитете, подражающих даже в ошибках…

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

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

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

Сейчас, с начала недели, кое-кто из канадского руководства “гостит” сейчас у нас, мы общаемся с новым директором всего украинского направления (дама, сама кст. говоря бывшая киевлянка, более 20 лет живущая и успешно работающая в Канаде), и она очень мудро спрашивала меня о том, сколько по каждому из наших направлений, где затребована работа дизайнеров или верстальщиков, мы общаемся с маркетологами? Как много информации, необходимой для работы, мы получаем напрямую от отдела маркетинга, а не отфильтрованную до сухих формальных фраз трёх проджект-менеджеров, каждый из которых (из лучших побуждений) на самом деле исполняет роль маленького испорченного телефона? Оказалось, что у нас прямого контакта-то и нету вообще. Информацию зачастую приходится получать косвенным образом, общаясь не только (и не столько) с project-manager`ами, но и с другими доступными менеджерами в  Канаде.

А теперь новая беда. Я не люблю перемены, даже если предчувствую, что они (глобально) к лучшему. Я боюсь перемен, меня они не радуют. Во многих жизненных ситуациях часто соглашаюсь удерживать не лучшую систему только потому, что привыкла к ней и мириться с недостатками этой системы мне проще, чем переделать всё. А у нас на этой неделе что ни день, то нововведения. Теперь вот переезжаем в почти новый офис, на этаж ниже. Команда растёт,  (кстати! нам очень нужны c++ и c# программеры! пишите если что) в одном помещении мы уже не помещаемся, теперь часть ребят останется на 4-м этаже, часть переезжает на 2-й. Разбивают их по технологиям-проектам. Одна проблема.

Дизайнеры принимают участие во всех проектах, в той или иной степени, вообще у нас нет ни одного проекта, для которого хотя бы иконочки и заставочки на инсталлятор не приходилось рисовать моей команде. А теперь как же? Придётся бегать между этажами, потому что во всём, что касается интерфейсов (особенно windows приложений) всё-таки не достаточно нарисовать прототип экрана и после утверждения порезать его на элементы, потом ещё приходится стоять над программером и смотреть, что он собирает в этой форме, как задаёт цвета и куда двигает элементы. Потому что не секрет, что программисты ни в жисть не заметят разницы между Microsoft Sans Serif и Arial, и уж тем более между шрифтом в 10 пунктом и в 11, а уж если речь заходит о более сложных объектах, лист вьювах и деревьях, то там просто начинается чуть ли не работа в четыре руки.

В общем, разделение команд на два этажа меня совсем не радует. Зато радует, что нашу работу оценили как достаточно серьёзную и успешную, и обещано присылать сюда ещё большие объёмы всего, и на отрисовку, и на макетирование, и на вёрстку, и на интеграцию. Так что дизайнерская команда опять будет расти и расширяться (солнышки, пожелайте мне успеха в том, чтобы найти хороших ребят в команду и в том, что бы мы таки справились!), и сейчас ищем как рисующих дизайнеров, так и верстающих. И в наших подкомандах тоже уже образуются как бы тим лидеры: предполагается по сценарию, что один из верстальщиков будет курировать работу новичков, проверять их код, ругать за баги и обучать качественной вёрстке. Я уверена, что он справится. Хотя на самом деле он тоже учится, с каждым проектом. Совсем недавно порекомендовала ему подписаться на лист на webstandardsgroup.org, он теперь почитывает и удивляется, в какие дебри и тонкости семантики порой влезают профи верстальщики, тут бы убедить руководство в пользе качественной вёрстки в противовес канадской вёрстке слайсами (а это — к вопросу, который обсуждался в заметке “О вёрстке, холиворах и реалиях“, когда нас ошарашили вопросом – где де ваши “слайсы”; канадские верстальщики на самом деле не утруждают себя тонкостями, а просто режут слайсами фотошопный эскиз).

В общем, происходит много всего, поэтому и пишу в блог в последнее время редко, просто не хватает на блог времени. И вот что интересно: что-то мне подсказывает, что новости на этом не заканчиваются, просто я ещё не всё знаю. Очень хочется, что бы изменения все были к лучшему. Вот.

Я тоже не сразу нашла. Честно говоря танцы с бубном пришлось исполнить. Знаете, что оказалось? Их мудрый верстальщик, или кто-то там, кто правил ресурсные файлы, открывал 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 выглядели зачастую пристойнее, а вёрстка – это просто песня, и я писала уже о качестве ихней вёрстки даже в этом блоге). У нас разное понимание того, что такое качество, и что такое профессиональная вёрстка, это уже ясно. Единственный способ – преодолеть на сегодняшнем митинге (собрание по громкой связи по телефону с их гоп-компанией) желание рассвирепеть и поругаться и попытаться, как бы это выразиться… обсудить конструктивно, обменяться технологическими процессами и знаниями для взаимной пользы и выработать (с обоих сторон) новые правила и критерии качества.

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

To know more about why styles are disabled on this website visit the Annual CSS Naked Day website for more information.

Уважаемые посетители! Не пугайтесь. У меня не слетели стили, этот блог не поломался и злые хакеры здесь не при чём. У этого блога (впрочем, как и у родительского сайта) просто отключена таблица стилей. Не случайно, не в следствии ошибки – это, господа, акция такая , подробности которой вы можете прочитать на CSS Naked Day. С целью поддержать веб стандарты. Незамысловато и просто. “This includes proper use of (x)html, semantic markup, a good hierarchy structure, and of course, a good ‘ol play on words.”

Когда-нибудь, если ситуация сложится, опубликую пример кода отвёрстанного канадскими верстальщиками веб-сайта, как живую иллюстрацию полного непонимания сути семантики, как пример того самого “абы как, главное, чтобы отображалось КАК НА ЭСКИЗЕ”. Зато при этом с гордостью – мы верстаем, типа, безтабличной вёрсткой. Нафига она нужна такая безграмотная безтабличная, даже сами объяснить не могут, что-то типа “сейчас так модно”. И при этом – опять те же заголовки (по логике документа) не тегом H*, а (в лучшем случае) спаном с классом, описанным в .css, в худшем – тегом font с атрибутами. И при этом хорошо, если классы используются, а чаще уважаемые канадские верстальщики юзают идентификаторы, причём ID с одним именем используется двадцать пять раз в одном документе (!), и очень смешно выходит у наших программеров: у них редактор настроен с включенной валидацией всего, что только можно, в том чисте включен чекбокс, не допускающий дублирования имён идентификаторов (что очень удобно на больших проектах, где задействовано много программеров – без шансов даже случайно задать имя, уже назначенное какому-то объекту), и в случае, если открывается документ, в котором несколько идентификаторов с одинаковым именем, то OPS! это имя остаётся только у одного объекта, у остальных автозаменяется на что-то типа Div1, Div2 etc.

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

А потом держаться за своих уже (почти-почти) классных верстальщиков, на которых тратилось время и силы, потому что страшно представить, что кто-то из них потеряется и нужно будет искать и обучать ещё и ещё.

UPD0: В блоге Юрия “akella” Артюха, на котором тоже отключены стили, нашла список так же участвующих в акции

UPD1: Вот по аське сделали замечание, что стоит попиарить сайт с веб-стандартами WSG (кстати интересно – не было единого мнения, где живут? *Russia 140* + Russian Federation 11*; а Ukraine при всём при этом – 32 зарегестрированных участника) и классику жанра – Zen Garden.

UPD2: А вот ещё на блоге visualstyle как-то не так давно (точная дата — 19 марта) мелькнула подобная идея, поверхностная реализация, фончики-цвета-цветочки. Мелькнула и пропала, и даже не обсуждалась, наверное, уважаемый soulskeeper думает, что блог никто не видит – не читает А мы всё видим.

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

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

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

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

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

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

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

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

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

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

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