Комментарии 66
Дизайн статичного макета нужен настолько же насколько нужна грамотная его реализация. Пока к сожалению нет удобных инструментов, позволяющих с достаточным уровнем абстракции дизайнеру (и именно дизайнеру) закладывать интерактивное взаимодействие. В этом направлении сейчас активно развивается Adobe со своим Xd (бывший Project Comet), а также по этому направлению постепенно идет Figma. Но пока это довольно сырые инструменты и говорить о преждевременном отказе от текущей парадигмы дизайна пока еще рановато.
Проблема скетча в другом — это жесткая привязка к платформе OS X -> macOS (хотя сам пишу этот комментарий с iMac все же нахожу это проблемой) и отсутствие зрелых инструментов работы с макетами на Linux, и Win. Ошибочно предполагать что за пределами макоси дизайна не существует и все должны работать только на маках(речь и про дизайнеров и про разработчиков). В этом плане у того же Фотошопа дела значительно лучше, хотя с версткой сложных макетов под линуксом до сих пор уйма проблем, единственное решение которых это виртуалка с нативным шопом. В этом плане очень жду когда доведут до ума Avocode (работа оффлайн, поддержка связанных объектов и артбордов, поддержка композиций).
Если смотреть шире — на рынке отсутствует единый кроссплатформенный инструмент дизайна, способный задать тренд в том «как это надо делать по-новому». Причем не обязательно чтобы на выходе получался готовый код но хотя бы чтобы это уже не была гифка уровня «должно дергаться как-то так». К сожалению пока приходится объяснять на пальцах либо использовать Edge Animate после проектирования дизайна в Ps. Вариант «сразу верстать» вместо дизайна очень часто приводит к ситуации огорода костылей в процессе демонстрации и двойной работе.
Не выдумывайте. Уже есть готовые инструменты в которых все сконфигурировано за вас и рассказано что нужно запускать. Вам нужно следовать инструкциям. Конечно какие-то технические знания придется подтянуть\получить.
Клиенты, кстати, в восторге когда им показываешь дизайн в браузере. Мы все чаще и чаще применяем этот подход.
Я думаю, что за таким подходом будущее и если дизайнер не будет учиться и развиваться, то в какой-то момент он окажется в положении в котором оказались актеры немого кино, которые отказывались сниматься в фильмах со звуком.
По личному опыту, в этом вопросе очень много противоречий, которые на данный момент не может решить ни один из существующих инструментов.
Ну и банальные «Инструменты разработчика», что есть
Ps: Фреймворки — это, конечно, круто и удобно, но начинать лучше всеж с основ, постепенно наращивая знания (А там, гляди, уже и свой фреймворк образуется)
Ниже я давал ссылку на Design In The Browser Bootstrap. Там есть инструкции по установке. К нему нужны зависимости (node, php). Инструкции по их установке тоже в сети можно легко найти.
Плюс у дизайнера наверняка есть коллеги-программисты, которые могут помочь разд-два настроить окружение, если возникнуть проблемы. Дальше дизайнер будет способен сам это сделать.
Во-первых, я и мои коллеги работаем используя дизайн в браузере. Я знаю об этом не понаслышке. Ниже я об этом писал.
Во-вторых, утверждение "Дизайнер должен дизайном заниматься используя соответствующие инструменты." не имеет под собой аргументов. Автор статьи привел аргументы почему он считает дизайн в браузере хорошей идеей. Я с ним согласен. Вы же в ответ просто говорите "должен и точка".
Ой, пропустил аргумент. Ваш аргумент — это годы вашего опыта. Только вот они ничего не говорят о том какой вы специалист. Когда я увидел этот "аргумент" я вспомнил собеседование человека, который утверждал что у него 7 лет опыта PHP. Да, он знал основы, но что происходит в современном мире и куда движется PHP и web в целом он представления не имел. Его знания о PHP остановились на стыке PHP 4 и 5. Другими словами из 7 лет его опыта работы он был 2-3 года (на момент собеседования) в теме происходящего. Возможно он хороший специалист в своем проекте и знает его вдоль и поперек, но он не соответствует современным требованиям к PHP-разработчикам.
Тоже самое с дизайном в браузере. Возможно сейчас это не так широко распространено, но я уверен что разрыв между дизайном и реализацией будет сокращаться за счет выкидывания излишних этапов и совмещения ролей. Я не знаю как дела обстоят у вас в стране, но в Беларуси еще 3-4 года назад компании искали отдельно верстальщика и отдельно javascript разработчика. Сейчас эти роли чаще всего совмещаются. Еще есть вакансии js-разработчика, но это обычно сложные приложения с большим кол-вом взаимодействия с бэкендом, а не просто взаимодействие с пользователем. Еще я изучал спрос в Великобритании и там похожая ситуация — отдельно верстальщик никого не интересует. И в огромном кол-ве вакансий для дизайнеров кроме инструментов которые вы перечислили требуется знание HTML/CSS.
В общем, как вам работать — это дело ваше. Я никого не заставляю делать дизайн в браузере. Я предлагаю подумать и, возможно, попробовать. Не хотите — не нужно.
Успехов!
Это проблема процесса работы с заказчиком, а не подхода. Вы будете страдать, если не построите нормальные отношения с заказчиком с любым подходом. Подумайте над итеративной разработкой. Грубо:
- Прототипы\wireframe (не в браузере)
- Минимальный дизайн в браузере
- Полный дизайн в браузере
- Правки дизайна в браузере
разве что кроме фреймворков
иначе это не дизайнер, а просто художник
Я считаю, что для того что бы знать где все поломается, а где будет работать, вы должны видеть материал и взаимодействовать с ним в его естественной среде обитания.
О, да! Я когда-то (во времена IE6) был верстальщиком и меня жутко бесило, что дизайнеры рисуют красивости без понятия что это реализовать невозможно (или очень трудно). Я тогда считал что дизайнер должен иметь представление о HTML, CSS и JS и как оно работает в разных браузерах. В идеале — должен уметь сам верстать и писать простенькие скрипты. Знакомые дизайнеры говорили, что не нужно дизайнеру это. Мол дизайнер — это человек искусства! Ага!
Сейчас в браузере, мне кажется, реализовать можно практически все и надобность знать техническую часть частично отпала. Все браузеры умеют png с прозрачностью и даже SVG! Но идея делать дизайн в браузере мне все равно кажется хорошей по упомянутым автором причинам. Мы с коллегами так и работаем. Прототипы делаются в разных инструментах (Adobe XD в последнее время), но дизайн делается в браузере в большинстве случаев.
Согласен с рекомендацией по Shay Howe. Очень хороший материал для новичков и для тех кто знает основы, но хочет подтянуть знания за последние лет 5. Там есть еще есть Advanced часть. Она немного слабей (в плане подачи материала), но в целом тоже хороша. Я сам читал по диагонали, но Жена недавно училась по его учебнику и очень осталась довольна.
Инструменты. Вы, возможно, слышали про подход который называют Atomic Web Design. Есть довольно неплохой инструмент Pattern Lab. Подход позволяет сделать декомпозицию вашего дизайна, а Pattern Lab помогает сделать что-то вроде стайл гайда в браузере и сразу писать шаблоны, которые потом смогут использовать на реальном проекте (больше всего подходит под PHP т.к. использует шаблонизатор Twig, но мы с Django проектами тоже используем — синтаксис похож).
Мои коллеги сделали Design In The Browser Bootstrap, который объединяет Pattern Lab и включает в себя готовые скрипты для сборки статики. Автопрефиксеры, ES2015 и т.д. Возможно будет полезно.
Ну на западе вообще профессии веб-дизайнера и верстальщика слиты в одну и часто (особенно на апворке) их не особо различают. У них даже такого термина как верстка нет толкового, при их любви к придумыванию новых слов. Фронтенд и верстка — это про разное, да.
Наш дизайнер уже года полтора подумывает про переход сразу к верстке, но барьером является, все-таки, порог входа в современную адаптивную верстку (см. пару комментов выше).
Во-первых: работа с браузерами не так проста, как нам бы того хотелось. Существует множество неочевидных хаков, которые необходимо применять в работе, чтобы макет не только выглядел как задумал его дизайнер, но и имел определенную структуру в html. Это «низкоуровневое» взаимодействие со страницей требует достоточно глубоких технических знаний от дизайнера. И это проблема.
Во-вторых: документацию и style guide всеравно придется создавать. Если, некоторое время спустя, сайт продолжит развиваться, то новые страницы будут верстаться в соответствии со стайл гайдом, чтобы соблюсти единообразие и гармонию между отдельными страницами.
В-третьих: статичный макет и сопутствующее руководство по стилю это универсальный формат. План строительства продукта, где описаны вся типографика, цветовая палитра и прочие паддинги с маргинами. Такой дизайн-документ можно использовать при создании не только сайта, но и приложений на различных платформах.
Итог: Качественный статичный макет в комплекте с документацией это не просто картинка в фотошопе. Это руководство по визуальной части для верстальщиков и программистов. Тут не происходит лишней работы в графическом редакторе, которую можно выполнить сразу в браузере, как и не происходит ее в работе архитектора ПО, когда он рисует UML-диаграммы, а не пишет сразу код.
У меня обычно все по старинке: html для разметки, css для стилей и js для сценариев. Современные тренды по написанию SPA под любые задачи мне кажутся лишь веянием моды: многие вещи в интернете должны оставаться просто текстовыми страницами (лендинги, визитки, блоги, новостные ресурсы и т.д.)
<Block name="header" options={ header_json }>
<Block name="menu" options={ menu_json }></Block>
</Block>
Тут все довольно примитивно и что-то еще упрощать смысла особого пока не вижу.
И при этом не забывать о ресурсах. Использование того или иного инструмента связано с ресурсами в первую очередь. При грамотной работе связка дизайнера и разработчика получается эффективнее.
Надо лендинг? Редимаг и Тильда (вот и браузер). Хотите рисовать в браузере? Фигма. Макет под разные экраны? Скетч и автолейаут? Протестировать простой интеракшн? Фреймер. А анимацию? Принсипл. И решение задачи каждым из этих инструментов может быть эффективнее одного универсального.
Ах да. Есть ещё Акшур, в нём можно не только попрототипировать, то и подизайнить (если очень хочется). И на выходе будет html (качество кода опустим).
Все же как приятно работать с готовым набором UI, а не генерировать грабли, которые снова ломаются при изменениях.
Ну а репозиторий своих компонентов для веб интерфейсов, для серьезного проекта, наверное должен быть всегда. Иначе просто не рационально делать / собирать фронтенд из горы граблей.
толковому дизайнеру просто надо знать и учитывать те или иные ограничения, плюсы и минусы сред, в которых его дизайн будет работать…
Такой процесс возможен только в том случае, если в вашем продукте функциональный подход и уже есть готовая библиотека контролов и шаблонов из которых дизайнер сможет слепить чтото новое. В противном случае просто огромная просадка по времени на согласования, доделки и полет фантазии.
Каждый специалист видит свое развитие по разному. Один дизайнер хочет и может полезть в разработку и способен начать сразу верстать, другому интересней анализировать данные и строить гипотезы, третий считает что пользователям будет комфортней если добавить персонажа с которым он сможет общаться и т.д. Сколько людей, столько и мнений. Я рад, что Вы нашли свой путь, но, к сожалению (или к счастью?), у каждого он свой.
Если нужен крутой лендинг, то алгоритм такой:
— находим профессионального редактора который работает над текстами, и придумывает общий образ подачи материала
— редактор в свою очередь нанимает по необходимости профессиональных художников-иллюстраторов, фотографов, видеооператоров, моушен-дизайнеров и т.д. для создания качественных «ассетов»/ресурсов которые будут составлять основу лендинга, т.е редактор берёт бразды правления над ними чтобы получить тот образ что он себе придумал
— далее результат передаём профессиональному web-дизайнеру, чтобы тот совместно с редактоом прошёлся по цветам, типографике при необходимости, минимальному пользовательскому взаимодействию если нужно
— далее передаём классному верстальщику, который хорошо знает свою работу. Ну и вобщем готово.
Если нужен какой-то дашборд или личный кабинет, то алгоритм такой:
— сбор и анализ требований/тз
— фронтенд разработчик проектирует/прикидывает интерфейс (хоть на листике, хоть в axure), при этом также при необходимости общается с бекендом и с бизнесом/заказчиком
— Далее результат отдаём web-дизайнеру, чтобы тут доработал композицию, цвета, типографику и возможно тексты
— далее уже нормальный макет передаётся назад в разработку
Как-то так…
Для этого стоит, я думаю, дизайнерам немного залезть в некоторые событийные моменты css/js. Ведь верстальщики, когда делают адаптивную верстку, тоже решают как будет выглядеть элемент.
И не принципиально как это будет выглядеть — как надстройка к графическому редактору, или веб-сервис с элементами графического дизайна.
не нужно чертить прибор, нужно сразу его строить
не надо составлять ТЗ на программу — просто пишите ее!
не объявляйте interface, рубите сразу рабочие классы реализации
Всем сомневающимся, что это (сабж) возможно и нужно:
Прозрите: автор принес вам истину!
Я по такой схеме делал свои первые сайты в 1997 году. Фотошопа на компьютере не было, приходилось с книжкой по html на столе писать код в блокнотике и выкладывать на сервер провайдера по фтп и смотреть в эксплорере, а потом переделывать, перевыкладывать и снова смотреть.
Молодежь такая молодежь, до слез просто.
1. Интерактивный прототип в axure
2. Дизайн в любом графическом редакторе по интерактивному прототипу
3. Верстка
4. Программирование.
5. Релиз
Хватит дизайнить в скетче. Делайте дизайн в браузере