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

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

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

И вот такая, казалось бы, мелочь пузатая, а не задача, становится трудно реализуемой из-за того, что какая-то скромная подзакладка (типа табов) по имени “IE PLUGINS” во французской версии называется “EXTENSIONS des fichiers IE”, а вспомогательный текст на специальной панели, так до пикселя размеченный, в эту панель просто не влазит. Делать панель больше? Значит, две другие, рабочие, нужно соответственно уменьшать. А с размером шрифта поработать нельзя, потому что у программеров шрифт задаётся в каком-то специальном объекте, одном на все текстовки. А размеры панелей у программеров где-то захардкодены так, что динамично изменять их в зависимости от локализации невозможно, а переделать – возможно, но (возвращаясь к вопросу о перепроектировании с нуля) “это займёт некоторое время”, которого нет у нас, нет в плане у PM`а, нет у заказчика.

Скажите мне только, почему так удивляется поставщик (сюда) задания, что чего-то сделать нельзя или можно, но “не быстро”? Задача-то месяц назад ставилась совсе-е-ем другая. Даже взять всего один элемент новшеств — те же языковые локализации, уже была бы другая концепция, изначально, и проектировалось бы другое, а ведь это только один, ближайший пример. И начинаются костыли, и разрушается логичная концепция, и у разработчиков опять состояние, близкое к тому, что это они — не профессионалы, работают над трудным, очень может быть что — неудачным проектом. А трудностей-то всего в том, что основная задача – костыли удержать да подпорки расставить. А тут ещё к ихним трудностям мы, мыши дизайнеры. У нас, видите ли, немецкая кнопочка сюда не помещается, а значит, нужно не просто текстбокс уменьшать, но и прогрессбар сдвигать, и ещё что-то там не состыковывается… А тут бы после добавления ещё (скажем так) 10% функциональности надо бы сценарии вывода интерфейсных окон изменить…

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

1. не расстраиваться, не брать на себя больше ответственности за неудачи в проекте, чем есть на самом деле; проблемы с дизайном интерфейса не всегда есть проблемами дизайнера интерфейсов.
2. не искать виноватых, а пересматривать цель (или ставить новую цель) и двигаться к ней; взаимные обвинения и перекладывания ответственности — путь в никуда, в том числе и для личной кармы разработчика;
3. не считать начальство абстрактным начальством, считать — партнёрами, но с функциями, отличными от своих, а значит, идти на контакт, терпеливо обучать и взаимообучаться (про условности и субординацию, правда, тоже забывать не стоит, и матом вслух ни-ни).

UPD: я ни разу не программист, так же, как и прочие дизайнеры в команде, поэтому большую часть проблем, которые нельзя решить, озвученных программерами, мы принимаем на веру. К примеру: заказчик хотел. чтобы интерфейс проги мог открываться на full screen. Программеры сказали: это не возможно в данных условиях реализовать на ближайшем этапе. Почему? Я не знаю. Но дизайнерам приходится работать в рамках фиксированных размерах окна. И таких примеров много.

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

Здесь моей работы-то было понты – найти в чём прикол и рассказать, что нужно сделать переменную, в которую передавать имя, и уже этой переменной назначать правила. Порешали. Но найти дизайнеру эту “ошибку визуального дизайна” не всегда бывает легко. Или вчерашнее: явно визуальный глюк. вылазят данные за декоративные границы блока. Как не кручу, как не экспериментирую с правилами в стилях или с вёрсткой – вылазят, гады, и всё тут. И, вроде, дизайнерская проблема… убила некоторое время на этот блок, кода на странице – больше 20 экранов, случайно обнаружила, что появился какой-то странный идентификатор в контейнере… имя явно не я давала, да и ID в моих контейнерах стараюсь не пользовать без особой нужды, а IDшники программерские по ходу всё равно большей частью динамические, я на них стараюсь и внимания не обращать (т.е. не обращаться по этим именам к блокам со своими .css правилами). Задаю поиск по всему проекту – кто и где использует это имя… Точно. Обнаруживаю в скриптовом файле обращение по этому id, и там идёт переназначение размеров блоку. Зачем это понадобилось – уже никто не помнит, но точно понадобилось ещё где-то в сентябре месяце, когда проект был значительно проще, и в этот блок информация выводилась линейная (а сейчас в зависимости от условий – 4 разные формы и на ещё две на сайте написано COMING SOON). Ага, очень дизайнерский “визуальный баг”. И такое – постоянно, ежедневно, в порядке вещей, да, подобными глюками у нас занимается дизайнер. А у вас?

Но тема из позапрошлой заметки была совсем о другом. Я, конечно, понимаю, что у VS и (помните ещё такого) уродского FrontPage одни родители; ожидать от режима “Design” чего-то другого было бы даже странно. Но вы представляете себе преогромный проект, да ещё и такой, где на каждой .aspx странице 90% кода визуализируются не сразу, а в зависимости от условий, а ещё на некоторые можно попасть (уже) только под реальными логином/паролем, да ещё и транзакцию провести – тестировать и обнаруживать ЕЖЕДНЕВНО визуальные глюки с самопрописанными размерами контейнеров, потому что продвинутые программисты в этом самом режиме “Design” очередной раз неаккуратно кликнули+дёрнули что-то мышкой? Или когда ещё один продвинутый программист написал минимодуль на странице, и скопировал туда копи-пастом из этого же режима контент, а потом они сутки меня ждали, чтобы я нашла, почему “расползлось” и при клике на крестике блок не показывается как должен по сценарию, а до этого минимодуля этот же блок нормально работал и показывался? А оказалось, что программер не посмотрел в коде – нужная информация была обрамлена в ОПРЕДЕЛЁННЫЙ контейнер с явно заданным именем идентификатора, по которому и скрывался-показывался. Т.е идентификатор с блоком просто потерял. Нашла, поправила, заработало. Но сам факт.

В комментах некий Евгений написал странный отзыв: “Ага, правильно, пускай программисты и за тебя работу делают, а ты будешь просто зарплату получать.” Мне бы очень хотелось, чтобы мне автор отзыва или другие программисты прояснили – что этими чудесными словами человек хотел мне сказать? Что есть две касты участников проекта – программисты (высшая каста) и дизайнеры (низшая), и что программисты, как высшая каста, имеют право работать в режиме Design, плодить для ПРОСТЕЙШИХ форм десяток вложенных друг в друга таблиц, терять свои же идентификаторы (что приводит к визуальным глюкам, которые решать, разумеется, должны дизайнеры) и ежедневно каждый на своей части проекта развлекаться и менять размеры контейнеро, участвующих в коде, а дизайнеры (низшая каста) должны работать уже с кодом, и за ними так же ежедневно ходить и делать одну и ту же работу про проверке – а что у нас тут “само” прописалось в коде на этот раз? Это правильно, это работа дизайнера? А слова “программисты и за тебя работу делать” – это в смысле, что если они не будут привносить мусорный код в документы, то это для них и будет “работать за дизайнера”?

В общем, всё не так плохо. Есть у нас программеры, с которыми я работаю уже не первый, и не второй год. И, кажется, с некоторыми даже не третий. Описанная выше проблема их не касается. С ними старая договорённость – да кидайте вы ваши серверные контролы В СТОЛБИК, и пишите свою логику дальше. Я заберу (через SVN), оформлю формы на высшем уровне. И работать с ними проще, и работы меньше, и глюков (почти) не бывает. Так где здесь они делают за меня мою работу?

А что касается дизайнеров (технических), то… я в самом деле запретила им верстать в нотпаде. Один паренёк долго сопротивлялся… Но там какие-то странные приципы и убеждения, вера в авторитеты (в его случае в совершенство ALS) и брезгливое отношение ко всем без исключения средствам разработки, предназначенных для разработки. Только код у него был… ну, в общем, как бы это помягче сказать… дело не в том, что сложнотабличное макетирование, дело даже не в постоянном мусоре и опечатках, дело в том, что человечку этому, видимо, совсем не надо вёрсткой заниматься – не видит он макета. Не умеет анализировать. Не логичная вёрстка. Какая там семантика. И вот интересно – такую же вёрстку можно было бы забабахать тем же FrontPage`м – так чем здесь гордиться? В общем, и у нас он не задержался (у нас были другие требования к вёрстке), и в следующей конторе тоже (именно за неряшливую вёрстку). Славный паренёк, но ему бы лучше только визуальным дизайном заниматься, необычным (где нет требований к юзабилити), эксклюзивным. Я бы порекомендовала посмотреть в сторону полиграфической рекламы. Или даже видео.

Но я не об этом. О том, что сама воспитанная на Macromedia HomeSite (помните такого чудика?) – до сих пор простую вёрстку в оном собираю. Но уже тесно – многих сервисов для кода у него нет и, понятное дело, уже не будет. Когда-то, в давние времена, приходилось верстать очень-преочень много “текстов” – там только абзацы-списки-картинки-ссылки, редко когда было более сложное макетирование. В хомсайте у меня были забиты функциональные клавиши на все сколько-нибудь однотипные операции, потому получалось быстро. Дизайнерам, дабы не мудрствовать и не изгаляться, предложила юзать DW, как наиболее на сегодняшний день гибкий для вёрстки кода и css (и в перспективе – не кинут, как HS) – не только подсветка кода (под почти все наши технологии), но и подсказки, не только для тегов, но и для css, работает с любыми кодировками включая уникод (в отличие от HS), только в режим Design не переключайтесь, говорю, на всякий случай, дабы не привыкать и впредь не повадно было А в той же VS, кстати, совершенно замечательнейший редактор кода! И очень удобное, очень преудобнейшее сворачивание контейнеров – как ни где в другом редакторе, не знаю почему. И подсветка парных тегов (наступил на тег из пары – можно в коде видеть где его пара. Или – что пару потеряли, тоже частая проблема). Ага, вот на страницах, где, как выше было написано, больше 20 экранов кода, только это и спасает.

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

Опять многа букоф? Ок, я молчу, теперь слово за вами. А как у вас? А что у вас? А как вы вообще?

Из простейшей (на первый взгляд) странице с редактированием профайла юзверя только что убила четыре (!) избыточные одноячеечные таблицы. Одна обрамляющая контент, одна – для блока с общими данными юзера, одна – для Change Password если юзер кликнул сменить пароль и одна – на Confirmation, если всё прошло успешно. На четвёртой не сдержалась, подзываю программера, мол, шо за дела? Мы же договаривались – ты вообще никакую вёрстку на странице не делаешь, кидаешь свои контролы в линейном порядке, я сама разрулю, как они должны ОТОБРАЖАТЬСЯ! А он мне отвечает… я, говорит, и не добавлял никакую разметку… оно, говорит, само. Он в студии, в режиме дизайн за один клик просто добавляет целый блок (размеченную форму) для, к примеру, смены пароля – со всеми необходимыми тегами, айдишниками и прочими атрибутами. Охренительная экономия времени! И вот при таких вот автоматизированных для ускорения работы программера действиях и добавляется, автоматически же, “контейнер” в виде одноячеечной таблицы, обрамляющей этот блок.

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

И вот я вышкаливаю пару талантливых юных верстальщиков. Ругаю за ошибки при анализе сетки. Если позволяет проект – заставляю перевёрстывать, объясняю, что вёрстка веб-страниц – это как раз та отрасль, где уместно применять свои способности к анализу. Потому что на самом деле это так, прежде чем вырезать из эскиза первую картинку, прежде чем написать первую строчку кода, первый контейнер, имеет смысл потратить время на то, чтобы понять макет, продумать для него его модульную структуру; и если на недовёрстанной ещё первой странице макета появляется необходимость какому-то классу переназначить правила с помощью ! important – значит, недопроанализировал, значит – всё заново (ага, и как раз пару дней назад такое было) перевёрстывать, благо есть возможность. В отличие, к примеру, от тех ситуаций, когда приходит сюда давно свёрстанный проект на доработку программерам, и спустя месяц вспоминают про дизайн (ой-ё, Таня, тут бы поправить бы), и ты прекрасно понимаешь, что поправить “честно” не выйдет. Или вместо 30 минут надо затребовать 3-4 дня на перемакетирование и перевёрстку всего этого разросшегося уже проекта, или – переназначение доменных правил, увы. Но если есть возможность – давайте продумывать макет изначально так, чтобы не было необходимости во всех этих important`ах.

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