В мире адаптивного веб дизайна, ограничения могут подбираться к вам с разных сторон: от привычек вашей пользовательской базы, до навыков вашей команды разработчиков.
В этой статье мы пройдемся по четырем вопросам, которые стоит задать вашей команде разработчиков прежде, чем начинать работу над разметкой вашей программы. Это позволит вам убедиться, что все друг друга понимают.
Вопрос 1: В каком виде вы должны передать итоговые материалы?
Я всегда предпочитаю уточнять существует ли какая-то определенная процедура передачи материалов, к которой привыкли разработчики. Этот момент может повлиять на то, какую программу вы будете использовать для создания макетов.
Я очень часто видел, как дизайнеры, и я в том числе, делали предположения о том, как нужно передавать материалы своей работы только для того, чтобы переделывать всё заново. Последнее, что нужно вашей команде, это чтобы вам, в последний момент, пришлось пересохранять или переделывать файлы в другом формате.
Ниже, приведены вопросы и сценарии, которые стоит обсудить с командой разработчиков прежде, чем приступать к работе над дизайном.
Как подготовить материалы?
Предпочитают ли они, чтобы вы разделили, подготовили и сохранили материалы в разных папках одной директории?
Может им проще будет получить исходный файл со всеми слоями, из которого они бы сами извлекли изображения?
Если да, то в каком формате? PSD? AI, EPS или PDF? Sketch?
Одинаковые ли у вас версии программного обеспечения? (смогут ли они открыть файл?)
Как вам назвать и сгруппировать слои, чтобы помочь им найти и выделить необходимые материалы.
Хотят ли они, чтобы вы извлекли HTML в Dreamweaver, или другим WYSIWYG редактором?
Если это ваш нормальный рабочий процесс, то спросите разработчиков устраивает ли он их. В 9 случаях из 10 они откажутся от этого метода.
Код, сгенерированный из программ с графическим интерфейсом, обычно некрасивый, неорганизованный, и неудобный. По своему опыту могу сказать, что этот метод замедляет работу как дизайнера, так и разработчиков. Избегайте кода, сгенерированного из программ с графическим интерфейсом. Всегда обсуждайте этот момент с разработчиком, если вы считаете это приемлемым вариантом.
Должны ли материалы сопровождаться документом о передаче?
Как вы планируете документировать неочевидные элементы дизайна? Такие вещи, как цветовые коды, ширина\высота, размеры шрифтов, отступы, начальные значения, эффекты парения, анимация, и другие данные, должны быть определены и записаны для того, чтобы разработчику не пришлось гадать.
Некоторые полезные приложения, которые помогут на этом направлении:
Omnigraffle. Упрощает рисование стрелок, добавление символов, и других элементов, помогающих объяснить особенности дизайна.
Avocode. Лично я никогда его не использовал, но этот инструмент позволяет экспортировать цвета, элементы изображений, шрифты, текст, CSS, и размеры из Photoshop или Sketch.
Inspect от InVision. Inspect обещает стать еще одним отличным инструментом для передачи материалов. В нем присутствуют комбинации функций продуктов, о которых я написал выше. Он особенно полезен, если для прототипирования вы используете InVision.
Вопрос 2: На какой платформе будет создаваться сайт?
Существует множество популярных платформ, которые существенно упрощают процесс разработки и дизайна. Для того, чтобы правильно составить документацию вам нужно знать какая платформа используется.
Много популярных платформ, таких, как Bootstrap и 960 Grid используют 12-колоночную систему. Почему именно 12 колонок? 12 лучше всего делится на меньшие цифры. Вы можете получить 12, 6, 4, 3, 2, или одну равномерно расположенные колонки, что упрощает для вас принятие решений.
Такая структура платформы располагает к предустановленным размерам. Знайте значения размеров вашей платформы с самого начала.
Случалось так, что края, которые я установил на артборде в Sketch, были на 5px больше, чем края в Bootstrap. По этой причине, мне приходилось переконфигурировать и перекодировать дизайн, чтобы исправить проблему, которой могло вообще не быть. Узнайте, на какой платформе будет создаваться сайт, и сделайте соответствующие изменения на своем артборде или холсте.
В дополнение к сетке, много платформ идет в комплекте со встроенными элементами дизайна, такими, как кнопки, надписи в формах, и т.п. Если вы собираетесь модифицировать или переписывать эти предустановленные стили, то позаботьтесь о том, чтобы об этом узнал разработчик.
Каждый раз, когда я создаю форму, с определенным цветом границы, радиусом и шириной, разработчики всё возвращают к дефолтным установкам, потому, что я не указал в инструкциях противоположного.
Не ожидайте, что разработчик заметит разницу радиуса в 2px, которую вы так тщательно выбрали для своих кнопок чтобы передать более дружественное ощущение. Они не обучены замечать такую разницу, зато способны, как машина, следовать заданному направлению.
Несколько самых популярных платформ:
- Bootstrap
- Foundation от Zurb
- Pure от Yahoo
- Skeleton
- Semantic UI
- …и десятки других
Узнайте, какую платформу используют ваши разработчики еще до того, как начинать работу над дизайном.
У большинства платформ есть ресурсы с шаблонами, которые вы можете легко найти и использовать чтобы подогнать под них ваш Sketch или Photoshop документ. Такой подход упростит всем жизнь.
Вопрос 3: Какие языки и библиотеки составляют среду разработки, и какие ограничения они несут?
Даже если вы сами не умеете писать код, то можете найти хороший виджет или плагин. Фрагменты кода упрощают добавление функциональности сайту. Уловка заключается в том, что плагины не универсальны.
Если вы захотите найти готовые плагины для своего сайта, то это вполне нормально, и довольно полезно. Только до этого, выясните, написанные на каком языке плагины вам нужно искать.
Каждый плагин или виджет пишется на том языке программирования, который выберет его автор. Может случиться так, что плагин или виджет, который вы выберете, будет написан на языке, не соответствующем языку или среде, на котором создается ваш сайт. Как вы понимаете, это может привести к проблемам, самой меньшей из которых будет сердитый разработчик.
Метеорологическое приложение, написанное на Ruby не будет работать, если ваш сайт работает на PHP. Слайдшоу плагин для WordPress не заработает, если ваш сайт создан на .NET.
Даже если вы найдете плагин, который совпадает с вашей средой разработки, то используйте его как пример, чтобы объяснить вашей команде какое поведение вы хотите увидеть. Разработчики могут предпочесть использовать его как есть, но вручение им ZIP файла, заполненного кодом, и просьба «вставить это в сайт», это, как если бы ваш клиент прислал вам письмо с несколькими миниатюрами, размером в 100px, и попросил бы сделать «одно из тех больших слайдшоу».
Вопрос 4: Какие браузеры мы должны поддерживать?
Новость: Не все браузеры созданы равными!
Ну ладно, это вы, наверное, знали, и если вы хоть раз встречали разработчика, то знаете, что Internet Explorer — это бич их существования.
К счастью для всего сообщества дизайнеров и разработчиков, различия браузеров, которые преследовали создателей онлайн контента в прошлом, быстро сужаются до узкого круга обидчиков. Даже Microsoft прекратил разработку Internet Explorer и занялся новым, дружащим со стандартами Edge.
Знание браузеров, которые вы должны поддерживать, может существенно повлиять на ваши решения. Вот список свойств CSS, которые не поддерживаются некоторыми старыми браузерами. Посмотрим, увидите ли вы тенденцию.
- Border-radius: IE8
- text-shadow: IE8, 9, Firefox 2, 3
- box-shadow: IE8, Firefox 2, 3
- RGBA (color transparency): ie8
- Flexbox (more on this later): IE8, 9.
- Multiple backgrounds: IE8, Firefox 2-3.5
- SVG: IE8 (many others for specific things)
- CSS Animation: IE8, 9, Firefox 2-4, Safari 3.1 — 3.2
- CSS 2D transforms (rotation, scale): IE8, Firefox 2, 3
- Media Queries: IE8, Firefox 2, 3
Если вы окажетесь в положении, когда вам нужно будет организовать поддержку IE8, или каких-нибудь особо старых версий Firefox и Safari — подумайте о том, как будут выглядеть элементы без добавления эффектов. Все ваши закругленные углы станут прямыми, анимация станет неподвижной, тени не будет видно, и т.п.
Создание дизайна с использованием новейших технологий, и в то же время сохранение его привлекательности и удобства в устаревших браузерах называется прогрессивным улучшением.
Я надеюсь, что эти вопросы помогут вам сформировать четкий путь общения с разработчиками в начале процесса проектирования. Понимание своих ограничений дает вам набор «правил», с которыми вы будете работать, и поможет решить множество, если не большинство проблем, возникающих в фазе сотрудничества дизайнера с разработчиком. Семь раз отмерь, один отрежь.
Перевод статьи Кевина Томассо
