Блог NunDesign

Всё-таки поставила эту последнюю версию WordPress`а… Как и обещали все, кто в русскоязычной блогосфере отписался про 2.5 и 2.5.1, новый интерфейс админки не то, что бы совсем ужасает, но выглядит крайне непривычным, да. Мешает всё. Мешает избыток этого небесно голубого (даже если сменить гамму на classic), мешает перелопаченная навигация. Какие такие продвинутые информационные архитекторы консультировали разработчиков на предмет того, почему довольно простую и понятную двухуровневую навигацию нужно разделить на четыре отдельных информационных блока? А эти аяксовые блоки, имитирующие popup-окошки? Какой умный дизайнер придумал делать верхушку этих блоков тёмно-серой, в тон затемнённому основному контенту так, что бы крестик, закрывающий блок терялся и замечался только при пристальном разглядывании?

Да, придраться есть к чему, но можно не вредничать и сказать спасибо - за фиксы в безопасности, за апдейт без глюков (я даже плагины поленилась деактивировать перед тем как). И бэкап не стала делать, а это совсем уж нагло с моей стороны. Сделаю постфактум, после апдейта

А вот ещё про бэкапы wp-блоггерам будет полезно: объявлен конкурс на лучший способ бэкапа блога, предлагайте ваши решения! Владимир Жилинский уже поделился своими идеями в посте “Резервирование и бэкап - зачем и как“.

И в качестве дополнительной приятности поставила плагин Gravatar, так что теперь в комментах могут показываться ваши авторские аватары. Зарегестрируйтесь на сайте http://www.gravatar.com/, залейте туда сколько хотите картинок ваших юзерпиков, выберите тот, который актуальный и всё. Дальше плагин сам найдёт, какую картинку подставлять в ваших комментариях. Посмотрите предыдущий пост - сразу видно, у кого есть граватары, а у кого стоят дефолтные заглушки!

В общем, надо покрутить, конечно, и потом уже делать выводы. Может и получится быстро привыкнуть. А по поводу всяких неудобных штучек в интерфейсе сегодня одна казусная ситуация напомнила такую спорную вещь: мы всегда стремимся упростить интерфейсные формы, упростить по-максимуму, в идеале - до одной функциональной кнопки. И вот появилась у нас форма с одной кнопкой, содержание (смысл и функциональность) которой менялось в зависимости от состояния формы. “запустить процесс”/”остановить процесс”, типа такого. Оказалось, что юзеров такая продвинутая функциональность сбивает с толку, они ВООБЩЕ не читают, что на кнопке написано. Поймав единожды содержание кнопки, юзеры не могут постоянно следить за кнопкой для того, чтобы узнать, когда содержание кнопки изменится. В том случае нам пришлось доработать кнопку визуальными средствами (Start был зелёненький, с текстом “Start”, а Stop - менялся цвет на красненький). Просто менять текст, не меняя ни расположение, ни форму - плохое решение.

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

А это скрин этой же формы, когда добавляется URL:

А какие интересные решения для подобных же форм вы встречали (или разрабатывали)? Так, чтобы и форма не избыточная, и юзер в заблуждение не вводится?

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

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

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

Не так давно к посту “Два вопроса про качественный в кавычках CSS” получила много полезных развёрнутых комментариев, спасибо всем. Напомню, что один из вопросов был о том, что если на странице есть кнопка-ссылка, к примеру, “Download”, то как правильно её реализовать: использовать конструкцию <a href=""><img src="" alt="Download" /></a>, где имидж в ссылке - красивая картинка для кнопки, или просто <a href=""></a>, где в описании класса фоном подгружать ту же красивую картинку? Правильно с точки зрения семантики, с точки зрения грамотной вёрстки и т.д. В комментариях были сторонники первого решения, были - второго, большей же частью писали о том, что без принципиальной разницы, по договорённости с главным менеджером. К примеру, заинтересовали такие критерии:

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

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

(more…)

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

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

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

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

What happened to the design?

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 думает, что блог никто не видит - не читает А мы всё видим.

Разработчики (и, в частности, дизайнеры интерфейсов, любых - веб, или windows приложений), если имеют опыт работы с разными командами, разными компаниями (т.е. разным руководством), сталкиваются с абсолютно разным представлением о том, что такое “правильный” интерфейс. Можно выделить три основные тенденции:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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