Комментарии 66
Мне кажется всю эту статью можно ужать в старый добрый «Keep It Simple, Stupid». Это крайне часто относится к дизайнерам и их мании величия («если не я, то от продукта клиент будет плеваться!»), но как правило чем проще, тем лучше и клиенту, и дизайнеру, и верстальщику, и, соответственно, кошелькам.
НЛО прилетело и опубликовало эту надпись здесь
Должен, только чаще дизайнеры больше походят на «девочек дизайнеров, оформителей интерьеров», умеют в 3DMax кубики собирать, но когда им говоришь, что сюда раковину не поставить ибо трубы в такую тонкую стену не залезут — округляют глазки и долго вдупляют, что же этот подлый дядька-строитель от них хочет…
C первой частью согласен. Вот только на лицо совсем иная ситуация. Очень много дизайнеров, называющих себя профессионалами, с версткой не знакомы абсолютно.
А касаемо «всего остального» — согласиться не могу. Лично знаю пару дизайнеров, которые не знают верстки, но умеют работать с SVG и всегда прикладывают шрифты.
А касаемо «всего остального» — согласиться не могу. Лично знаю пару дизайнеров, которые не знают верстки, но умеют работать с SVG и всегда прикладывают шрифты.
Побольше бы таких статей.
Спасибо!
Спасибо!
Их и так уже вагон и маленькая тележка… :)
Видимо мало этих вагона с тележкой, раз до сих пор приходится об этом всём писать.
Зачем же писать всё то же самое и переливать из пустого в порожнее...?
Достаточно дать ссылки на уже написанный качественный материал. :)
Достаточно дать ссылки на уже написанный качественный материал. :)
Цитируя Хабраэтикет:
Если схожие темы неоднократно поднимаются под разными предлогами, это не значит, что надо ставить минус. Это лишь значит, что проблема до сих пор не решена.
Проблема во многом надуманная.
А окончательно она будет решена, когда появятся совсем уж гибкие для верстальщика инструменты и возможности. А нужен ли будет тогда верстальщик...? :)
Хотя и сейчас уже столько всего напридумано, что сверстать можно любой макет, было бы желание и достаточная квалификация у верстальщика.
Да и вообще, для меня понятия «веб-дизайнер», «вебмастер» — человек, который способен красиво нарисовать и качественно сверстать задуманное.
А окончательно она будет решена, когда появятся совсем уж гибкие для верстальщика инструменты и возможности. А нужен ли будет тогда верстальщик...? :)
Хотя и сейчас уже столько всего напридумано, что сверстать можно любой макет, было бы желание и достаточная квалификация у верстальщика.
Да и вообще, для меня понятия «веб-дизайнер», «вебмастер» — человек, который способен красиво нарисовать и качественно сверстать задуманное.
Какая проблема — надуманная? Недостаточная квалификация некоторых дизайнеров? Или проблема взаимодействия обеих сторон? Простите, не могу согласиться ни с тем, ни с другим.
Как и с тем, что проблема решится только с появлением какого-либо гибкого инструмента. У меня в команде, например, очень профессиональный дизайнер и такой проблемы попросту нет уже несколько лет. И я лично знаю еще несколько веб-дизайнеров, которые знают свою работу и делают ее хорошо — так, что с их макетов верстать легко и быстро. Но вместе с тем есть масса и обратных примеров.
А насчет «сверстать можно любой макет» — конечно. Внимательно перечитайте статью. Там в самом начале указаны последствия верстки непрофессионально созданных макетов.
Если честно, у меня создается ощущение, что мы с Вами о разных проблемах говорим))
Как и с тем, что проблема решится только с появлением какого-либо гибкого инструмента. У меня в команде, например, очень профессиональный дизайнер и такой проблемы попросту нет уже несколько лет. И я лично знаю еще несколько веб-дизайнеров, которые знают свою работу и делают ее хорошо — так, что с их макетов верстать легко и быстро. Но вместе с тем есть масса и обратных примеров.
А насчет «сверстать можно любой макет» — конечно. Внимательно перечитайте статью. Там в самом начале указаны последствия верстки непрофессионально созданных макетов.
Если честно, у меня создается ощущение, что мы с Вами о разных проблемах говорим))
Помните, как в Матрице — «ложки не существует» :)
Так же и здесь — проблемы, обозначенной в статье, не существует.
Проблема только в кадрах.
Если мы говорим о профессионалах, то как для дизайнера, так и для верстальщика, а также и для дизайнера-верстальщика сделать конфетку проблем не составит.
Если речь идёт о «любителях-нелюбителях», то Крылов об этом уже всё сказал: "… А вы, друзья, как ни садитесь, Все в музыканты не годитесь"…
Так же и здесь — проблемы, обозначенной в статье, не существует.
Проблема только в кадрах.
Если мы говорим о профессионалах, то как для дизайнера, так и для верстальщика, а также и для дизайнера-верстальщика сделать конфетку проблем не составит.
Если речь идёт о «любителях-нелюбителях», то Крылов об этом уже всё сказал: "… А вы, друзья, как ни садитесь, Все в музыканты не годитесь"…
Проблема только в кадрах.
Это настолько же верно, насколько и банально. Кроме кадров, в нашей сфере и нет ничего. Ни станков, ни заводов, ни логистики даже толком. Офисы и ПО — да и без первого обходятся все чаще. Указывая, что проблема только в кадрах, Вы лишь подтверждаете ее наличие.
Люди становятся профессионалами не сразу. Многим подобные статьи как раз и помогают в таковых превращаться.
Мне вообще кажется все это странным. Зачем такое жесткое разделение обязанностей? Зачем рисовать сайт в фотошопе попиксельно? Дизайн это так, приблизительный внешний вид. Приблизительный.
Должно быть так — идеологи придумывают функционал сайта, определяют что где будет находиться, меню там всякие и формы ввода, совместно с дизайнером придумывают приблизительные эскизы страниц. Пусть в фотошопе, но эскизно. Далее разработчики делают сайт, пытаясь при этом минимизировать его размер, количество всяких картинок, скриптов и прочего шлака, что мы закачиваем мегабайтами каждый раз при заходе на страницу. Максимизируют скорость загрузки (для этого в конторе должна быть специальная машина, желательно старая и дохлая, с зарезанной до предела скоростью интернета и древней операционной системой, по возможности с вирусами). И самое главное — разработчики повышают удобство работы, логичность всего на сайте.
А дизайнер смотрит на все это, на промежуточные этапы, на конечный результат, на юзабилити сайта и говорит — вот здесь шрифт нечитаемый, здесь сочетание цветов неадекватное, здесь слишком мелко, здесь неровно и т.д. То есть советует, корректирует работу в процессе и оценивает результат. А не рисует никому не нужные макеты в фотошопе и не заставляет нас, пользователей, закачивать тонны никому не нужных шрифтов, картинок и css-ок.
Должно быть так — идеологи придумывают функционал сайта, определяют что где будет находиться, меню там всякие и формы ввода, совместно с дизайнером придумывают приблизительные эскизы страниц. Пусть в фотошопе, но эскизно. Далее разработчики делают сайт, пытаясь при этом минимизировать его размер, количество всяких картинок, скриптов и прочего шлака, что мы закачиваем мегабайтами каждый раз при заходе на страницу. Максимизируют скорость загрузки (для этого в конторе должна быть специальная машина, желательно старая и дохлая, с зарезанной до предела скоростью интернета и древней операционной системой, по возможности с вирусами). И самое главное — разработчики повышают удобство работы, логичность всего на сайте.
А дизайнер смотрит на все это, на промежуточные этапы, на конечный результат, на юзабилити сайта и говорит — вот здесь шрифт нечитаемый, здесь сочетание цветов неадекватное, здесь слишком мелко, здесь неровно и т.д. То есть советует, корректирует работу в процессе и оценивает результат. А не рисует никому не нужные макеты в фотошопе и не заставляет нас, пользователей, закачивать тонны никому не нужных шрифтов, картинок и css-ок.
НЛО прилетело и опубликовало эту надпись здесь
И снова все неоднозначно.
Например, моя команда работает как раз примерно так, как Вы и описали (с тем лишь различием, что макеты, все же, готовим полностью, а не эскизно). Но мы за пять лет сработались и знаем, что друг от друга ждать.
Если же брать наиболее частый случай, когда команда собирается только на один-два проекта… Я очень сильно сомневаюсь, что описанный Вами подход сработает. Фронтендщики, а уж тем более — программисты, не очень шарят в дизайне, уж простите. И доверять им формирование внешнего вида сайта, пусть даже в деталях, я бы, как руководитель, не стал. Мне жалко дизайнера.
И не совсем понял, при чем здесь «никому не нужные макеты» по отношению к тоннам статики. Это уже частности, я о них как раз в статье и написал))
Например, моя команда работает как раз примерно так, как Вы и описали (с тем лишь различием, что макеты, все же, готовим полностью, а не эскизно). Но мы за пять лет сработались и знаем, что друг от друга ждать.
Если же брать наиболее частый случай, когда команда собирается только на один-два проекта… Я очень сильно сомневаюсь, что описанный Вами подход сработает. Фронтендщики, а уж тем более — программисты, не очень шарят в дизайне, уж простите. И доверять им формирование внешнего вида сайта, пусть даже в деталях, я бы, как руководитель, не стал. Мне жалко дизайнера.
И не совсем понял, при чем здесь «никому не нужные макеты» по отношению к тоннам статики. Это уже частности, я о них как раз в статье и написал))
После придумывания приблизительных эскизов страниц будет сделан приблизительный дизайн, позже отдан, приблизительно, верстальщику для приблизительной верстки, после чего приблизительная верстка будет натянута на приблизительный бэкенд. Отдел тестирования приблизительно протестирует и опишет приблизительные баги. Команда сдаст такой проект в приблизительный дедлайн и получит приблизительный к описанному в контракте оклад.
Это не работает в случае разработки сайтов под ключ. В них дизайн является самой важной составляющей сайта. В таком случае выгоднее сделать дизайн, согласовать его с заказчиком, внести пожелания и уже только после этого начать верстать, чем верстать страницы до согласования с заказчиком. В первом случае несколько раз работает дизайнер и 1 раз верстальщик, а во втором оба работают по несколько раз.
А как можно всего этого не знать?
Можно. В смысле, нельзя, но встречается. И чаще, чем хотелось бы.
Я очень люблю дизайнеров, их работа действительно важна. И от того еще сильнее расстраивают, когда сталкиваюсь с подобными вещами.
Я очень люблю дизайнеров, их работа действительно важна. И от того еще сильнее расстраивают, когда сталкиваюсь с подобными вещами.
Да легко. Уже больше 10 лет есть высшее образование на графдизов этого врофиля, но спрос настолько велик, что их катастрофически не хватает. По моим прикидкам в России только 1% веб-дизайнеров имеет профильное образование.
Долго читал заголовок, пытаясь понять, кто такой Дизайнь…
С аналогичной проблемой я столкнулся на своей текущей работе римерно 2 года назад.
Внедрение и использование стайлгайда частично решило проблему. Теперь у дизайнера перед глазами все функциональные элементы и, перед тем как ваять что-то новое, дизайнер пробегает глазами по тому, что уже есть.
Полностью, от дизайнерских полётов фантазии, стайлгайд не спасает. Но всегда есть возможность прислать дизайнеру ссылку на аналогичный элемент и поинтересоваться, почему именно на этой странице должно быть что-то другое.
Пользуясь случаем, хочу пропиарить свою библиотеку для быстрого создания стайлгайдов: https://github.com/sneas/component-library. Использую её на своём текущем проекте. В папке /demo есть пример того как встроить стайлгайд в процесс сборки на галпе. В /demo/gulpfile.js можно увидеть пример подключения.
Внедрение и использование стайлгайда частично решило проблему. Теперь у дизайнера перед глазами все функциональные элементы и, перед тем как ваять что-то новое, дизайнер пробегает глазами по тому, что уже есть.
Полностью, от дизайнерских полётов фантазии, стайлгайд не спасает. Но всегда есть возможность прислать дизайнеру ссылку на аналогичный элемент и поинтересоваться, почему именно на этой странице должно быть что-то другое.
Пользуясь случаем, хочу пропиарить свою библиотеку для быстрого создания стайлгайдов: https://github.com/sneas/component-library. Использую её на своём текущем проекте. В папке /demo есть пример того как встроить стайлгайд в процесс сборки на галпе. В /demo/gulpfile.js можно увидеть пример подключения.
Каждый шрифт, который вы хотите использовать в макете (если он не входит в список «безопасных»), должен быть представлен как минимум в четырех форматах: ttf, eot, woff (или woff2, а лучше оба) и svg.
Если я и получу от дизайнера шрифты сразу во всех веб-форматах, то толку от них будет мало, скорее всего. Из шрифта нужно вырезать неиспользуемые символы, сделать хинтинг, прописать нормальную высоту строки, чтобы на всех ОС вертикальное выравнивание было одинаковым.
И, кстати, забудьте вы уже про шрифты в svg, идея изначально была бредовая.
Благородно и похвально, честно. Как-нибудь надо провести опрос, сколько фронтенд- разработчиков так же серьезно относятся к шрифтам. Боюсь, не очень много. Но фронтенд — это тема отдельной статьи.
Раз уже зашел разговор про оптимизацию шрифтов, до я тихонько пропиарю свой модуль для ноды, где все вышеперечисленное выполняется автоматически.
сделать хинтинг, прописать нормальную высоту строки, чтобы на всех ОС вертикальное выравнивание было одинаковым.
А вот про это можно поподробнее? Сам фронтэндщик, но как правильно поступать с этими параметрами не знаю до сих пор, к сожалению
По-русски про это написано мало, но недавно прочитал от гугла неплохую вводную статью, по поводу вертикального выравнивания большинство ссылок уже устарело, но можно почитать тут, а как делать это на практике тут. Вообще, FontForge — это инструмент №1 для работы со шрифтами(по крайней мере для меня). Сообщением выше я уже написал про свой модуль для ноды, который делает все сам.
В чьей зоне ответственности оптимизация svg ( т.е. уменьшение узловых точек, выравнивание по пиксельной сетке, по возможности максимальное использование простых примитивов круг, квадрат, полигон и последующее их объединение при необходимости вместо фигачинья кистью 100500 точек) — дизайнера или верстальщика?
Если верстальщик явно видит что некое растровое изображение в макете простое и явно будет меньше весить в svg — можно ли требовать от дизайнера перерисовать в кривых?
Если верстальщик явно видит что некое растровое изображение в макете простое и явно будет меньше весить в svg — можно ли требовать от дизайнера перерисовать в кривых?
Скользкий вопрос.
Я всегда возлагал оптимизацию SVG на дизайнера. Это графика. Верстальщик может пропустить и не заметить какой-то элемент. Точку там или даже глаз — такое бывало.
Последние года полтора-два мы вообще используем только векторные иконки. И если приходится работать со сторонним дизайнером, то я всегда прошу предоставить набор SVG. Очень часто это приводит к увеличению сроков, так как дизайнер присылает те самые «псевдо-SVG». Но такова жизнь.
Но если верстальщик сам немного дизайнит, или, например, в команде так заведено — ради Бога.
Я всегда возлагал оптимизацию SVG на дизайнера. Это графика. Верстальщик может пропустить и не заметить какой-то элемент. Точку там или даже глаз — такое бывало.
Последние года полтора-два мы вообще используем только векторные иконки. И если приходится работать со сторонним дизайнером, то я всегда прошу предоставить набор SVG. Очень часто это приводит к увеличению сроков, так как дизайнер присылает те самые «псевдо-SVG». Но такова жизнь.
Но если верстальщик сам немного дизайнит, или, например, в команде так заведено — ради Бога.
Да ладно, чаще всего дизайнер даже не понимает чем отличаются разные варианты экспорта svg. Не понимает разницу между встроенными и инлайн-стилями, или атрибутами. Если на странице используется инлайновый svg, то криво-экспортированный svg может доставить кучу проблем с отображением, начиная от непонятных масок, заканчивая слетевшими цветами.
Да. Именно поэтому я и вынес эту историю в отдельный пункт про SVG. Веб-дизайнер должен уметь работать с SVG более глубоко, чем «экспортнуть из фотошопа». Надеюсь, в ближайшем будущем ситуация поменяется и дизайнеры поймут, насколько важен для веба вектор.
Если есть проблемы с вектором, который дал дизайнер, мы отправляем его обратно на доработку (хотя в ряде случаев быстрее и проще самим поправить). Здесь многое зависит от того, будет ли сотрудничество долговременным.
Дизайнеры далеко не так глупы, как их часторисуют. У меня за всю SVG-историю с ними только раз был инцидент с «нехочунебуду». Почти всегда дизайнер, даже если не понимал, о чем мы его просим, довольно быстро разбирался в теме.
Если есть проблемы с вектором, который дал дизайнер, мы отправляем его обратно на доработку (хотя в ряде случаев быстрее и проще самим поправить). Здесь многое зависит от того, будет ли сотрудничество долговременным.
Дизайнеры далеко не так глупы, как их часторисуют. У меня за всю SVG-историю с ними только раз был инцидент с «нехочунебуду». Почти всегда дизайнер, даже если не понимал, о чем мы его просим, довольно быстро разбирался в теме.
Если честно, то я не совсем могу понять эту проблемы про с svg. 99% из 100 иконки и так уже векторные, если говорить про PSD. Даже представить сложно кто сейчас рисует только с учетом 96 dpi. Хотя, быть может я просто с откровенно плохими дизайнерами не работал.
Некоторые веб-дизайнеры не берут готовые иконки, а рисуют их сами. Растром. Или находят в вебе, и копируют в макет. Тоже растром. И когда потом просишь их предоставить вектор, возникают проблемы. Это в случае с фотошопом.
С дизайнерами, работающими в Sketch, немного проще. Но тут все равно остается актуальным вопрос с «data:img/png;base64» и оптимизацией. Если это иконки знака вопроса, а весит она как чугунный мост, стоит задуматься.
С дизайнерами, работающими в Sketch, немного проще. Но тут все равно остается актуальным вопрос с «data:img/png;base64» и оптимизацией. Если это иконки знака вопроса, а весит она как чугунный мост, стоит задуматься.
А я требую от дизайнера собюдать вот это: https://github.com/andrey-hohlov/psd-templates-requirements и буду рад пулл-реквестам
Спасибо за статью, прочел с интересом. Сам я frontend-ер и работал с несколькими дизайнерами. Некоторым из них я бы с удовольствием скинул эту статью :-)
Единственное, хотел бы возразить пункту «Помните про адаптивность». Адаптивность — это да. Но не такими жертвами — делать несколько макетов под каждое разрешение. Это очень дорого. Я работал с дизайнером, у которого в отдельном txt было описано поведение каждой страницы при каждом пороге разрешений (для Bootstrap). Примерно так:
И еще — добавьте в статью информацию о фавиконе) Это обязанность дизайнера, а фавиконов в макете почти всегда нет :(
Единственное, хотел бы возразить пункту «Помните про адаптивность». Адаптивность — это да. Но не такими жертвами — делать несколько макетов под каждое разрешение. Это очень дорого. Я работал с дизайнером, у которого в отдельном txt было описано поведение каждой страницы при каждом пороге разрешений (для Bootstrap). Примерно так:
Категории товаров
до 970px уменьшается ширина элементов
при меньших экранах блоки размещаются друг под другом.
Блоки с преимуществами
Сначала уменьшается ширина блоков в соответствие со столбцами.
При экранах от 750 и меньше
блоки скидки и торговая марка размещаются под блоком доставка
При экране 320px блоки занимают всю ширину экрана и размещаются друг под другом.
Хиты продаж
Уменьшается количество выводимых товаров.
Для 1170 - 6 товаров, 1 товар занимает 2 колонки
для 970 - 4 товара, 1 товар - 3 колонки
для 750 - 3 товара, 1 товар - 4 колонки
для 480 - 2 товара 1 товар - 3 колонки (всего 6 колонок)
для 320 - 2 товара, 1 товар - 3 колонки (всего 6 колонок)
И еще — добавьте в статью информацию о фавиконе) Это обязанность дизайнера, а фавиконов в макете почти всегда нет :(
Адаптивность адаптивности рознь. Не сказать, что я не совсем не доверяю верстальщикам, сам из них, но не всегда перестраивание элементов — такая простая задача. Всегда есть отступы, позиции кнопок, иконки — тьма не самых очевидных для фронтендера нюансов. И потом смотришь на сайт — все, вроде, на месте, а глаз режет. Даже при наличии инструкций. Хотя здесь кое-что зависит от масштаба проекта и «дизайнутости» верстальщика.
Насчет favicon — это тема отдельной статьи, и недавно на хабре она уже
публиковалась. Фавиконок нужно довольно много, не говоря уже о манифесте и прочем. Не думаю, что стоит повторяться с такой малой периодичностью.
В ряде простых случаев достаточно воспользоваться вот этим ресурсом, если нет возможности запросить у дизайнера favicon.
Насчет favicon — это тема отдельной статьи, и недавно на хабре она уже
публиковалась. Фавиконок нужно довольно много, не говоря уже о манифесте и прочем. Не думаю, что стоит повторяться с такой малой периодичностью.
В ряде простых случаев достаточно воспользоваться вот этим ресурсом, если нет возможности запросить у дизайнера favicon.
НЛО прилетело и опубликовало эту надпись здесь
Почему всё-время пиарят эти сетки? Оне вроде бы же ограничивают как-то дизайнера, разве нет?:
«сначала нужно сделать хорошо, а потом уже заниматься сеткой” https://youtu.be/trf-C-MI5x8?t=18m10s (скорость лучше х1,5)
http://artgorbunov.ru/bb/soviet/20131104/
я, например, эту вырвеглазную сетку вообще отключаю, только мешает продумать/увидеть общую архитектуру компонентов. По-моему с помощью flexbox-ов, свойства calc и единиц измерений vw, vh можно построить любую сетку (могу ошибаться), а всякие бутстрапы это избыточно, максимум оттуда взять отдельные элементы можно (попап-окна, чекбоксы)
По поводу адаптивности — тоже как-то напряжно когда дизайнер даёт 25 макетов под все возможные разрешения. Мы договорились что он рисует под максимальное и минимальное разрешения (может ещё быть промежуточный вариант под какой-то конкретный айпад если сильно нужно), а разработчик уже делает компоненты резиново-адаптивными в этих пределах на своё усмотрение, когда компонент начинает „ломаться“ при уменьшении ширины и нужно принять компромиссное решение, зову дизайнера и спрашиваю „что делаем? перескакиваем на следующий ряд или прячем элемент? картинку кропаем или просто уменьшаем?“ (так вроде легче и быстрее всем). Да и пиксель-перфект это как-то уже старомодно и не рационально, выше правильно написали — что надо корректировать уже походу дела с дизайнером ок/не ок. Это как-бы и есть командная работа всё-таки.
«сначала нужно сделать хорошо, а потом уже заниматься сеткой” https://youtu.be/trf-C-MI5x8?t=18m10s (скорость лучше х1,5)
http://artgorbunov.ru/bb/soviet/20131104/
я, например, эту вырвеглазную сетку вообще отключаю, только мешает продумать/увидеть общую архитектуру компонентов. По-моему с помощью flexbox-ов, свойства calc и единиц измерений vw, vh можно построить любую сетку (могу ошибаться), а всякие бутстрапы это избыточно, максимум оттуда взять отдельные элементы можно (попап-окна, чекбоксы)
По поводу адаптивности — тоже как-то напряжно когда дизайнер даёт 25 макетов под все возможные разрешения. Мы договорились что он рисует под максимальное и минимальное разрешения (может ещё быть промежуточный вариант под какой-то конкретный айпад если сильно нужно), а разработчик уже делает компоненты резиново-адаптивными в этих пределах на своё усмотрение, когда компонент начинает „ломаться“ при уменьшении ширины и нужно принять компромиссное решение, зову дизайнера и спрашиваю „что делаем? перескакиваем на следующий ряд или прячем элемент? картинку кропаем или просто уменьшаем?“ (так вроде легче и быстрее всем). Да и пиксель-перфект это как-то уже старомодно и не рационально, выше правильно написали — что надо корректировать уже походу дела с дизайнером ок/не ок. Это как-бы и есть командная работа всё-таки.
Насчет сетки не согласен, но каждый работает так, как ему удобно. По моему мнению, визуальная структуризация адаптивности невозможна без гридов или их аналогов.Сверстать-то можно все, с этим никто не спорит. Однако тогда легко скатиться в бездну «если не видно разницы, зачем платить больше».
О том, почему не всегда стоит перекладывать адаптивность на верстальщика, я выше уже писал. Описанная Вами схема работает отнюдь не всегда. Велика вероятность того, что итог работы будет не самым лучшим, потому что где-то надо грамотно расставить пропорции блоков, где-то заменить иконку на текст, где-то просто убрать элементы. И далеко не всегда верстальщик способен (да и должен) правильно это сделать. Просто потому что он не дизайнер и не проектировщик.
Пиксель-перфект же нерационален только в случае, если предварительное взаимодействие с дизайнером не прошло на должном уровне. Если дизайнер в своей работе не учел реалий — например, фреймворка. Мы же хотим жить в идеальном мире, правда? Так давайте попробуем сами сделать его немного лучше хотя бы в той сфере, в котором работаем))
О том, почему не всегда стоит перекладывать адаптивность на верстальщика, я выше уже писал. Описанная Вами схема работает отнюдь не всегда. Велика вероятность того, что итог работы будет не самым лучшим, потому что где-то надо грамотно расставить пропорции блоков, где-то заменить иконку на текст, где-то просто убрать элементы. И далеко не всегда верстальщик способен (да и должен) правильно это сделать. Просто потому что он не дизайнер и не проектировщик.
Пиксель-перфект же нерационален только в случае, если предварительное взаимодействие с дизайнером не прошло на должном уровне. Если дизайнер в своей работе не учел реалий — например, фреймворка. Мы же хотим жить в идеальном мире, правда? Так давайте попробуем сами сделать его немного лучше хотя бы в той сфере, в котором работаем))
О том, почему не всегда стоит перекладывать адаптивность на верстальщика, я выше уже писал. Описанная Вами схема работает отнюдь не всегда. Велика вероятность того, что итог работы будет не самым лучшим, потому что где-то надо грамотно расставить пропорции блоков, где-то заменить иконку на текст, где-то просто убрать элементы. И далеко не всегда верстальщик способен (да и должен) правильно это сделать.
Согласен, именно поэтому я и написал, что в такие моменты зовём дизайнера и ОБЩАЕМСЯ. Если нужен какой-то конкретный промежуточный вариант с идеальной композицией (например заказчик просматривает результат на своём айпаде) — пусть отдельно отрисовывает под это разрешение, не проблема.
Спасибо за интересную статью!
«Научитесь работать по гридам» — а не проще написать Научитесь работать по модульным сеткам?
SVG это боль, да. Недавно прислали макет в котором SVG нарисованы с помощью clip mask или чего-то такого (извините, я не силён в терминологии SVG) и когда я их совал в icomoon, то сайт либо ругался на меня, что нужно stroke (могу ошибаться в термине) конвертировать в path, либо рисовал чёрный квадрат на месте катушки Кинопоиска.
Мастерство заголовка. «Дизайнь» — это что за слово?
Вполне нормальное слово.
вы бы предпочли «Дизайнируй»?
А какой глагол может быть производным от существительного «дизайн»?
А зачем создавать производные? Существует множество слов которые не склоняют.
Cлово дизайн (design) может использоваться как глагол.
У вас в тексте есть отличный пример:
Некоторые рекомендации для дизайнеров, делающих мир чуть светлее.
Это слово воспринимается как существительное дизайн, написанное с ошибкой. Нужно приложить усилия, чтобы увидеть в нём глагол.
Купив фотоаппарат, я стану фотографом, борную машинку — стоматологом, Фотошоп — дизайнером. А после прочтения этой статьи, меня полюбят все верстальщики…
Нет, не бывает дизайнеров, не знакомых с правилами типографики, не отличающих гротеск от антиквы, не слышавших о понятии вертикального ритма, «выключки» или висячей пунктуации.
Не существует ни одного дизайнера интерфейсов, не читавшего труды Чихольда, Альцшуллера или Нильсена. И каждый из них знает про законы Фиттса и Хика, его интерфейсы проходят на тестирование «переполнения контентом», а анимация описывается бо´льшим смыслом чем «красивая» или «плавная».
Потому что именно эти знания позволяют понять, почему после абзаца следует отступ, что динамика требует связности, а переопределение — доступности. Только знание правил позволяет их же и нарушать, а не «вот этот блок сюда, ему нужно больше „воздуха“». Иначе я возьму в руки скальпель и начну лечить этих «дизайнеров», потому что «мне идёт этот халат».
Нет, не бывает дизайнеров, не знакомых с правилами типографики, не отличающих гротеск от антиквы, не слышавших о понятии вертикального ритма, «выключки» или висячей пунктуации.
Не существует ни одного дизайнера интерфейсов, не читавшего труды Чихольда, Альцшуллера или Нильсена. И каждый из них знает про законы Фиттса и Хика, его интерфейсы проходят на тестирование «переполнения контентом», а анимация описывается бо´льшим смыслом чем «красивая» или «плавная».
Потому что именно эти знания позволяют понять, почему после абзаца следует отступ, что динамика требует связности, а переопределение — доступности. Только знание правил позволяет их же и нарушать, а не «вот этот блок сюда, ему нужно больше „воздуха“». Иначе я возьму в руки скальпель и начну лечить этих «дизайнеров», потому что «мне идёт этот халат».
Не после прочтения. После кропотливой и довольно серьезной работы, на которую может сподвигнуть прочтение этой статьи.
Нет, не бывает дизайнеров, не знакомых с правилами типографики, не отличающих гротеск от антиквы, не слышавших о понятии вертикального ритма, «выключки» или висячей пунктуации.
«Вы не поверите»…
Увы, действительность такова, что часто приходится выбирать из того, что есть. В любой области, и дизайн — не исключение. Относительно недавний яркий пример: человек «рисует» очень неплохо, заказчикам нравится, но вот он имел весьма смутные понятия о том, как всё нарисованное реализуется в конечном продукте, и потому зачастую появлялись проблемы. При этом категорически ленился заняться самообучением, хотя мог бы зарабатывать больше в этом случае.
Я не дизайнер, и не верстальщик, и скажу спасибо если мне кто-нибудь объяснит, почему веб-дизайнер и веб-верстальщик настолько разные и гордые профессии, что не просто не пересекаются, но и, по всей видимости, считают это ниже собственного достоинства.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Дизайнь как верстальщик