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

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

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

Получается, что мы должны (пусть ещё и в начале разработки, но всё же уже на лету) менять постановку задачи в целом: для кого всё-таки пишется инструмент? Если заказчик планирует выйти с ним на рынок и рекламировать для универсального пользователя, тех же домохозяек в том числе, он и должен получить продукт для универсального пользователя и домохозяек в том числе; ни к чему тогда такая развёрнутая функциональность, сложные формы, диаграммы и визарды разрешения конфликтов синхронизации данных (долго писать, но как раз этот визард, просто шедевр проектирования с моей точки зрения, удобный и понятный для всех наших и даже одобренный заказчиком, поставил в тупик 100% тестировавших из той самой фокус-группы неподготовленных пользователей). Да, разрабатывается совсем другая программа. И пусть весь интерфейс сводится к двум кнопкам, например, зелёной и красной (да, одной не обойдёшься, бывает), зато легко будет разобраться.

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

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

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

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

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

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

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

В какой-то степени Женя прав, даже с меркантильной точки зрения в нашей компании (где программеров в любом случае раз в 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 бит/с.

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

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

1. Правильный интерфейс – это функциональный интерфейс. В таких командах главный упор делается на продуманный механизм разрабатываемого проекта, на идеальный движок, все силы уходят на то, чтобы ядро было безупречным, чтобы (web или windows) приложение работало без сбоев при любой нагрузке, чтобы максимально полно и качественно реализовать затребованные заказчиком функции и сделать доступными управление этими функциями из интерфейса приложения. И складывается так, что для разработки этого приложения (или ряда приложений) привлекаются лучшие, высокооплачиваемые специалисты-разработчики, аналитики и программисты. Такие факторы, как удобство пользования этим приложением или уж тем более красота интерфейса, считаются вторичными, это приводит к тому, что и специалисты подбираются уже менее тщательно, команда специалистов незначительна по сравнению с командой программистов (обычно вообще один-два человека, иногда даже удалённых). Функциональность реализована, но пользоваться ею неудобно, а о визуальной привлекательности лучше не вспоминать.
2. Правильный интерфейс – это удобный интерфейс. Забота о пользователе ставится во главу угла (я не говорю о том, что это не правильно). Для разработки привлекаются талантливые информационные архитекторы, проектировщики взаимодействия, специалисты по юзабилити-тестированию, удивительно, но факт: в команде на пять программистов – семь ответственных талантливейших человек, отвечающих за создание правильного интерфейса + привлечённые для тестирования (эмуляция целевой аудитории) люди. Работу свою они выполняют качественно, приложение получается на самом деле с интуитивно понятным интерфейсом, удобное в использовании, только вот группа разработчиков подводит – то у них база падает при увеличении нагрузки, то кнопка нажимается через раз, да и сама функциональность не достаточно продумана и реализована поверхностно, хотя другие разработчики из этой же темы давно уже ушли на порядок вперёд. Удобно, но не функционально и не привлекательно.
3. Правильный интерфейс – это красивый интерфейс. В последнее время приходилось анализировать большое количество как виндовых программ, так и веб сервисов, встречались среди них примеры с на самом деле привлекательным, талантливо исполненным интерфейсом – очень эффектные веб сайты, необычайно и привлекательно отрисованные формы программ, с гармонично подобранными цветовыми гаммами и потрясающей графикой. Честно говоря, ни одно из них не осталось под руками в работе, отношение к ним осталось, как к миленьким игрушкам, которые стоило запустить, чтобы посмотреть, что там у нас рисуют западные прогрессивные разработчики, полюбоваться и забыть навсегда ввиду абсолютной непрактичности приложения. Не говорила бы об этом примере, если бы не сталкивалась. В такой ситуации разработка приложения в целом – это постоянное дорисовывание и перерисовывание интерфейса, его элементов, в процессе разработки делается 50 вариантов эскизов и на ежедневных митингах с руководством 90% времени – это обсуждение того, почему у этой иконочки “вот видите? зубчик на скруглении неаккуратный”, а “вот эта панелечка на один пиксель левее остальных”, и такое прочее. Команда же программеров чувствует себя изгоями – они не получают чёткую постановку задачи, им не дают технических возможностей реализовать всё достаточно правильно, им не дают человеко-ресурсов (когда в команде пару человек более-менее грамотные, остальные 10-15 – новички типа студенты), и даже времени на правильную реализацию.Типичный пример: так, ребятки, нам для послезавтрашней презентации сделайте быстро и красиво первую, пилотную версию (делают, что успевают, но к презентации версию предоставляют). А потом после презентации попытки объяснить руководству, что этот прототип был сделан в спешке на скорую руку, и для правильной реализации дайте же нам две недели! Две недели не дают, говорят, что функциональность устраивает, но через месяц разработки, когда костыли под костылями уже не удерживают конструкцию, удивляются и оскорбляются – что вы, мол, возитесь, и почему у вас всё время ничего не работает! Работает, но кое-как. В подобных ситуациях зачастую: красиво, но неудобно и не функционально.

Недооценка важности какого-то этапа, или низкие критерии качества любой части процесса разработки встречаются часто и в большинстве случаев снижают качество работы в целом, иногда – обесценивают (и я была свидетелем того, как закрывались практически готовые, разработанные проекты ввиду их полной коммерческой нецелесообразности при данной реализации, а бюджета на полную переделку уже не было). Часто это приводит к безграмотному использованию человеческих ресурсов. Я встречала, к примеру, в целом неплохую команду разработчиков (что-то около 40 программеров, большей частью веб-сервисы) – и на всю команду ВООБЩЕ ни одного дизайнера, ВООБЩЕ ни одного грамотного верстальщика. Помню, сколько времени талантливый дотнетчик тратил на то, чтобы хоть как-то причесать интерфейс, по ходу разбираясь с тонкостями вёрстки, с html и css и консультируясь по поводу подбора цветов для оформления интерфейса и элементов интерфейса. И это в то время, когда гораздо рациональнее и для конторы в целом выгоднее, если бы он писал только свой движок – но у конторы некому поручить эту работу, а тот удалённо сотрудничающий с ними индус, который рисует им эскизы для интерфейсов (дико уродские, честно-честно) и потом их “режет” в базовую html вёрстку (адаптацией вёрстки в движок он никогда не занимался и поэтому понятия не имеет, отчего матерятся программеры и после его трудов полностью перевёрстывают полученный макет).

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

Приведу цитату (скопировано из раздела “советы” на сайте Артёма Горбунова):

Все физические проявления хорошего интерфейса эстетичны — экраны, текстовый набор, иллюстрации и визуализации. Плохой интерфейс уродлив.
[Тафти, Рудер, Херлберт, Мюллер-Брокман, Брингхерст и другие...]

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

1. Получить визуальный стиль, который качественно будет отличать его от конкурентов (т.е. не затеряется в общей массе);
2. Получить визуальный стиль, который качественно будет отличать его от конкурентов в лучшую сторону;
3. Вызывать расположение у потенциального клиента, положительные эмоции;
4. Способствовать (или не мешать) росту аудитории и повышению уровня продаж.

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

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

Впрочем, каким-то ветром и к нам некоторое время назад прибило клиента, который заказал два дизайна и стиль для них пожелал (креативный, а как же) – необычный, нетрадиционный, “crazy” – хоть тема была обычная себе, видимо, маркетинговый отдел посчитал, что среди аудитории продукта не достаточно пропахана ниша бездумных обкуренных подростков. Ещё один, выходящий за рамки “традиционных решений” – дизайн, который паренёк рисовал для музыкальной группы – но здесь тоже можно было проявить смелост, даже с риском нарваться на осуждение за перегибание палки – аудитория довольно узкая, тут и в самом деле надо иметь не самое обычное видение мира, чтоб такую музыку слушать. Т.е. здесь контент фильтрует аудиторию сайта, и с обратной стороны так же – сайт (со своим крези дизайном) фильтрует аудиторию поклонников группы. Или, кажется, простая работа – иконки на программу, общая (которая после инсталляции на десктопе видна, к примеру), к ней же на инсталлятор пара иконок install/uninstall; обычное решение – от основной порождается пара путём добавления плюсика(зелёного)/минусика(красного) или стрелочки/крестика; дизайнер предлагает – а давай я сделаю не обычное решение, операцию инсталляции или наоборот показывать обручем с тенью зелёного цвета вокруг основной иконки (раз он уже привычно ассоциируется с развитием и – с инсталляцией) , а удаления – с обручем красного цвета с тенью. Ан нет. Это не традиционное решение. А вдруг юзер подумает, что красный кантик – это новое приложение, и будет кликать, чтобы вызвать программу, и удалять нашу разработку со своего компа! Это же что же – плохое (не своевременное) решение в дизайне опорочит престиж всей разработки? Нет. Сделайте красиво. Креативно. Модно. Не похоже на других. Но в традиционных рамках. Да.

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

У меня на блоге сейчас несколько счётчиков для статистики. Есть, к примеру, Google Analytics, есть — два значительно отличающихся по визуальному стилю сервиса обработки статистики. И вот дизайн дизайном, но и GA, и, скажем, LI, как и локальный и любимый когда-то AWStat – они обычные и понятные, их навигация прозрачна (пусть и отличается в тонах-полутонах, данные читабельные и тут же дают картинку-представление о том, что там у нас происходит). Reinvigorate (с модным дизайном в псевдостиле web2.0) хоть и нравится в целом (не удаляю уже сколько месяцев), но не рабочий он какой-то… Хотя, очень может быть, если бы понадобилось делать презентаху с отчётом о посещаемости, я бы графики от туда брала. Ещё очень нравится листинг с данными о реферерах – откуда пришёл, если оттуда – на какую конкретно страницу и тут же – юзерские параметры, какая ОС, какой браузер… И листинг-то в целом получается избыточный, на самом деле, и большая часть экранов – неразумное использование пространства, вот к примеру:

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

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

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

Ну да, поскольку весь блок Welcome выполнен в стиле записной книжки с закладками, как будто бы сценарий не должен быть неудобным – мы держим в руках книгу, и мы “отворачиваем” страницу с закладкой (она становится слева, и слева же – все закладки, соответствующие уже прочитанным страницам), а справа – актуальная закладка + все остальные закладки, соответствующие непрочитанным блокам. Кажется, ничего военного, но для веб-интерфейсов решение не совсем традиционное, и по началу неудобное. Дело не в самом наличии вертикальных закладок – дело в их перетекании справа-налево и наоборот при необходимости, по началу теряешься. Но. Если это сделали Corel, значит идею сопрут и повторят ещё тысячи других компаний, которые разрабатывают программы для Win, и подобное решение для навигации в интерфейсе вполне может стать нормой. Да, нужно учитывать, что CorelDraw и остальное из пакета – это не программы для… развлечений, где наличие навороченных нетрадиционных скинов является нормой с момента их разработки и выхода на рынок. Но то, что “нормально” для, скажем, WinAmp`а, то может оказаться недопустимым для сложнейшего графического редактора. Идея, суперуместная для дизайна портфолио творческой личности, не подойдёт для сервиса статистики. Загадочная, похожая на шараду флешевая навигация, реализованная для регионального подросткового проекта, но не годится для электронного магазина, торгующего пластиковыми окнами.

Так они и не договариваются – заказчики, которые хотят (выгодно) отличаться от конкурентов, и разработчики, творческие личности, которые не любят рутину и тоже хотят создавать уникальное и вечное.

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

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

Недавно, почти довёв до совершенства RadControls Tabstrip`овские закладки под поставленную задачу наткнулись, что как раз незатейливую заказанную клиентом фичечку реализовать просто не получается, контрол же сам по себе – ничего военного, со всем напором юношеского энтузиазма убедили руководство выделить для работы нам время, и сели с программером его сочинять. Я ему прикинула модель тегов, расписала, где нужны будут идентификаторы и где куда мне генерить какие именованные классы (разумеется, использовали в разметке двухуровневые ненумерованные списки) , и какими спанами куда и что обрамить (первоуровневые элементы по событиям визуально становятся похожи на закладки же ж со сглаженными краями, но при этом ПРОИЗВОЛЬНОЙ ШИРИНЫ). Дальше была разделённая работа – я писала таблицу стилей, программер – логику выгребания из xml имён первого уровня, второго уровня, да в зависимости от определённого при авторизации статуса юзера, да… короче, написали. Супер получилось. Вот кстати тогда он и поделился информацией (с ужасом, как мне показалось), что в некоторых фирмах подобные контролы пишутся программерами при НЕЗНАЧИТЕЛЬНОЙ дизайнерской поддержке (ну, там, придумать-нарисовать эти самые картинки на закладки и, возможно, порезать их же).

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

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

И я не против, когда разработчик хочет себе высокую оплату своего труда, и сама убеждаю руководство, что платить надо больше, и меня, разумеется, радует, что учиться они всё-таки хотят, только реально учатся пока медленно почему-то, но повторять стопятый раз фразы типа “у таблицы нет атрибута valign!” “что опять делает padding в стиле картинки? Создаёт поле от картинки до неё же?” “опять незакрытые теги! Опять не закрыты картинки, br`ы, но ладно, здесь просто обучиться. Но абзацы-то, абзацы мы научимся закрывать?” Я уж не говорю про лекции о семантике и логике, обычной логике. Ладно один из верстальщиков (оправдываясь, обиделся) говорит “я же говорил, что ещё не освоил дивную вёрстку и буду верстать пока таблицами, вы же разрешили!” – Б-блин. Да. Подтверждаю. Разрешила. Сделать колоночный макет таблицей. Но.Напрудить мне десяток (а в целом – 24) вложенных таблиц для того, чтобы РАЗМЕТИТЬ В ОДНОЙ СТРОКЕ ПЯТЬ ЗАГОЛОВКОВ И ПЯТЬ СТРОЧЕК ТЕКСТА вложенными таблицами – это уже не имеет отношение к дивной вёрстке, это, извиняюсь, имеет отношение к ОСНОВАМ HTML и ОСНОВАМ ЗДРАВОГО СМЫСЛА, будут они обижаться или нет. Ок, разобрали с ним вёрстку на примере того, что делал он и того, что переделывала я (не изменив своего обещания разрешить таблицу для колоночного макета, свести весь макет из 24 таблиц к одной), отметили те атрибуты, которые просто являются ошибкой (т.к. не существуют и не работают), те атрибуты и теги, которые являются логической ошибкой (т.е. нарушают логику документа и, как следствие, усложняют вёрстку, прежде всего из-за непредсказуемости ошибок, хрен найдёшь потом почему у него что-то куда-то уползло), и те, которые в целом написаны верно *(с т. зр. логики вёрстки), но избыточно, т.е. код, который в оптимизированном виде использовать проще, да оно и нагляднее получается с т.зр. читабельности всего созданного филе другим разработчиком или даже этим, скажем, через недельку.

Со вторым там всё ещё более запущено. Меня, конечно, безмерно радует энтузиазм, желание быстрее научиться и делать правильно, но ошибки, которые генерит второй, пугают больше. Сами понимаете, если верстальщик не закрыл, к примеру, абзац, большого горя он никому не принёс. А вот если какой-то рульный контейнер (div), описание которого задаёт поведение всех дочерних объектов, а потом пол дня ищет, почему у него всё разъезжается, или ещё хуже, делает плавающую модель и удивляется, почему соскакивает блок (не понимаю, говорит, почему, я же размеры линейкой из макета в фотошопе снимаю!), а обнаруживается, что родительскому объекту задан фиксированный width (ой, а откуда это? я этого не писал! это DW сам прописывает!) потому что в режиме “Design” в DW он где-то как-то за что-то потянул, а потом в коде не проверил… и.. ой, ну там короче много всего, больше похожего на анекдот (я почти уверена, что он не издевается, что он не специально).

В общем получается, что на большие дотнетовские проекты вывести ни одного из них не могу. Для примера показывала им среду VS, объясняла, что валидатор должен быть включен у всех программистов, но если на одну программерскую ошибку валидатор станет выдавать двести ошибок вёрстки дизайнерской, то это… несколько усложнит работу над проектом в целом… и отношение к такому усложнившему работу дизайнеру будет даже не с профессиональной т.зр., а с чисто человеческой, отнюдь не суперским. Ещё тёмную устроят. Шутка.

Заодно пришлось подгонять откровенным шантажом. Объяснять одну простую тупую вещь. Если я из одного проекта в другой буду каждый вечер сидеть до десяти вечера в офисе и ПЕРЕДЕЛЫВАТЬ работу, набодяженную нашими капризными и такими требовательными к уровню зарплаты труженниками веб-девелопмента, то нафиг надо тратить фирме зарплатный фонд на поддержку их капризов? Я согласна на премиальные, сделаю сама, как и раньше – когда я одна работала, в целом работы, может быть, было и поменьше, но не в шесть раз, точно не в шесть, и – успевала, тяжело было, но хотя бы контролируемо (хочешь сделать хорошо, сделай это сам!)

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