Блог NunDesign

Ещё вчера, пока писала “Офисное дизайнерское: стандарты и договорённости” была уверена, что столько всего нужно записать из “правил и договорённостей”, важных для успешной командной работы дизайнеров, а как до дела дошло, так, кажется, и писать нечего. Большая часть – такие очевидные вещи, что даже странно, что их нужно оговаривать особо. Но, с другой стороны, если были прецеденты больше двух раз, значит, имеет смысл записать себе очередной пунктик.

Вот, к примеру, такая интимная вещь, как организация фолдеров и файлов на дизайнерском компьютере: каждый, кто приходит в офис, пытается создать себе такую структуру, какая уже была у него на домашнем компьютере или на предыдущей работе. Иногда рабочие файлы запрятаны в глубь поддиректорий или даже разбросаны по разным дискам — от десктопа и “My Documents” на C: до совершенно невообразимых путей разной глубины на других дисках. А представьте себе, если по ходу горячей работы дизайнер внезапно не пришёл с утра на работу (мало ли, заболел), или, что ещё чаще бывает, в конце рабочего дня отправил эскиз и благополучно ушёл домой, и тут обнаруживается, что в отправленном допущена ма-а-аленькая ошибка, которую НАДО исправить сегодня, потому что она должна уйти в работу для канадских интеграторов, у которых рабочий день только начался. И что? Им терять целый рабочий день?

Я, обычно, всё равно задерживаюсь на 2-3 часа позже остальных наших творческих личностей, и часто бывает так, что по ходу дорабатываю что-то из их исходников (ошибки или замечания канадских менеджеров), но запоминать все уникальные структуры для файлов надоело. А компы дизайнерские все типовые и размечены одинаково на два диска, С и D. Поэтому был введен локальный корпоративный стандарт:

• Все рабочие проекты живут на диске D в папке projects, в которой создаются папки с именами, соответствующими проекту, для которого ведётся работа. Даже если по этому проекту дизайнеру нужно было нарисовать одну единственную иконочку – исходник для неё, версии и результирующий файл должны лежать в папке с именем этого проекта, никаких temp или other!
• Если проект контролируется через SVN, папка с дизайнерскими исходниками по проекту должна лежать в общей папке проекта, просто не добавляется в SVN.

Следующий трабл обнаружился, когда оказалось, что дизайнеры нифига не хотят уделять внимание именам файлов тех эскизов-иконок-экранных окон, которые они создают/отдают в работу верстальщикам или программерам. И ходит в работе очередной “test123.png”, потом “Первая Проба 123-1.png” (ага, вот так вот, через пробелы), потом “!!!my last test123-5.png” или ещё что похуже, и разобраться в собственных версиях картинок, или даже идентифицировать быстро, для какого проекта какая из картинок рисовалась, в какой-то момент не может уже сам дизайнер, не говоря о том, какие проблемы возникают, если нужно срочно передавать его работу другому. Поэтому мы договорились именовать файлы так:

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

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

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

• Все слои должны быть именованы в соответствии с содержащимися в них объектами. Группы слоёв должны быть объединены в Set`ы (Groups) требуемой вложенности, и тоже должны быть именованы. Все эти Layer68 и Group29 – самый удобный способ запутать партнёров по проекту.
• В случае, если в одном файле включены группы слоёв для разных экранов (разных разделов сайта или программы), базовые группы должны полностью визуализировать экран. Чтобы не надо было догадываться, что для экрана такого-то нужно включить второй слой (контент), 28-й (шапка с формой) и 69-й (меню с правильно подсвеченным элементом меню), а для… ну, понятно, в общем.
  

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

• Cценарии поведения объектов – кнопок, табов, элементов меню.
  

  Замечательно получилось, когда на один из проектов дизайнер всё хорошо сделал и продумал – и структура групп, и имена слоёв. Картинка была хорошо порезана, проект (не web, а windows приложение), всё скомпановано. Потом дизайнер уволился, а у нас возникла задача сгенерить интерфейс для языковых версий. А навигация по разделам вся — рисованная, и по задумке дизайнера все элементы навигации – чуть отличаются друг от друга, и каждый элемент при этом имеет пять состояний (normal, active, over, press, disable). И сценарий на смену каждой кнопки дизайнер ДЕРЖАЛ В УМЕ: вот для нормальной “этот” слой – 80% opacity, для over – 100%+включается “вот этот слой”, для disable – 63% + выключается “вот этот слой”. Замечательно, но как мы с другим дизайнером, которого спешно пришлось ставить на этот проект, “угадывали” эти сценарии для генерации состояний элементов… в общем, такого быть не должно.

• Ещё немного очевидных вещей – типы шрифтов. Правила должны быть достаточно строгими: для текстов, которые будут использоваться в проекте, использовать только стандартные шрифты, все тексты с нестандартными шрифтами завёрстываются картинками. Уж сколько раз твердили, повторяли, настаивали…
  

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

• Anti-aliasing — больная тема. Опять же, если текст должен в проекте быть текстом, он и в эскизе должен быть не размытым, с выключенным anti-aliasing (=none). Очевидно? Казалось бы, да, но упорно не соблюдаемо.
  

  Это вызывает серьёзные спорные моменты, особенно для заголовков, которые (в сл. веб проектов) или жирные, или не жирные, сделать вёрсткой заголовок, который должен быть текстом, стандартным шрифтом и чуточку тяжелее, чем его regular (заметно на тех же, скажем, Tahoma+regular+Sharp anti-aliasing) практически не возможно. И, как всегда, отмазка, мол, сделайте уже как-нибудь.

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

Хорошую заметку прислали, на английском, специально прямо для наших канадских творцов: “10 Tips For Creating Website Mockups In Photoshop“. Но я бы не стала так уж прямо привязываться к первым двум пунктам, или же сформулировала бы по-другому. Всё-таки простые формы в дизайне экранов – это частный случай, а не обычное решение. А как часто и мои дизайнеры, и я сама в скетче что-то не векторное дорисовываем ручками, доводим до идеального состояния. Да, эскиз получается не масштабируемый легко, ничего не поделаешь. Простые векторные формы, плоский стиль подходит не для 100% задач.
Ещё важно, из того, что должен отслеживать дизайнер на этапе создания макета (а не отдавать на волю верстальщика или программиста) — как должен выглядеть интерфейс при разных разрешениях экрана:

• если дефолтный скетч рисуется для разрешения экрана 800х600, проверить, как он будет смотреться при разрешениях 1200х1024, 1600х1200;
• если предполагается резиновый дизайн, показать, как он будет тянуться и куда что ползёт, какие элементы продолжают выравниваться от центра экрана, какие выравниваются по правому/левому краю, как изменяются размеры панелей;
• если предполагается фиксированный дизайн – показать выравнивание по отношению к центру экрана;
• то же касается экранов для windows-программ – как выглядит интерфейс при изменении размеров программы, её минимальный размер + full screen.
• если предполагается фиксированный дизайн, но с неоднородным основным фоном, показать поведение фона при изменении размеров окна и (к примеру) центрировании рабочей области.