Как стать автором
Обновить

Комментарии 28

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

Уже сейчас для этого реализуется система линеек и направляющих, что существенно ускорит работу над макетом. Уже есть перемещение объектов с шагом в 1 и 10 пикселей (по стрелочкам и с зажатым Shift'ом). Запланированы хоткеи: выделение, перемещение, копирование, удаление группы объектов. Да и сама группировка с функцией фиксации позиционирования и отдельно оформления тоже будет. И т.д.

В итоге, надеемся, что получится не медленнее, а может даже быстрее, чем в Фотошопе. По крайней мере, делаем всё для этого возможное…
Не в том направлении вы движетесь. По своему опыту: самая главная беда дизайнеров — отсутствие реиспользуемых визуальных компонент. Чтобы интерфейс очередной странички/панельки не приходилось заново вымерять по пикселям, а один раз нарисовав компоненты просто сконструировать из них то что надо в едином «корпоративном» стиле. Это значительно сэкономит время как дизайнера, так и верстальщика, который также не может переиспользовать код из-за разброда в дизайн-макетах.
Вот вам гугловая поделка для вдохновения: www.polymer-project.org/tools/designer/
У меня в Акшуре зачастую получается работать быстрее, чем в фотошопе. Плюс интерактивность, плюс какой-никакой html.
На видео я насчитал 6 вложенных DIV для картинки. Это ужасно. Не знаю что там устарело, но лучше я буду динозавром, чем работать с такой версткой.
Также очень дельное замечание. На видео ранняя альфа-версия сервиса, генерация кода реализована на уровне прототипа, чтобы примерно показать, в каком направлении она будет развиваться. Согласитесь, если будет максимально оптимизированная автогенерация, оставаться динозавром нет смысла. Но на данный момент согласен — альтернативы нет. В статье рассматриваются скорее не текущие решения, а общий вектор, куда идет и когда-нибудь придет развитие.
"… получаем лаконичный и красивый код."
image
Использовал webflow.com на протяжении года, удобно для дизайнера, который делает простые посадочные страницы или имеет много времени для чего-нибудь посложнее. Сейчас перешел на бутстрап в редактор кода, в первую очередь из-за прозрачности работы с кодом и возможностей автоматизации рутины, чего в конструкторах практически нет.
Как по мне, для продуктивного взаимодействия между дизайнером и верстальщиком нужно всего три вещи:

1) Всех дизайнеров в принудительном порядке отправлять на курсы вёрстки (азы, месяца занятий пару раз в неделю хватит).
2) Объяснить дизайнеру такие понятия как «вертикальный ритм» и «сетка» (удивительно, но мало на каких курсах про это рассказывают).
3) Следовать принципу «код первичен, дизайн вторичен» (под кодом подразумевается архитектура проекта, а не тупо HTML).

После этого дизайнер может смело возмущаться на тему: «почему вон там кнопка съехала на 1 пиксель». А пока у меня в макетах у каждого блока разные поля в 43, 21, 19 пикселей и 5 вариантов серого цвета типа #acacac, #bcbcbc мне разговаривать с дизайнером не о чем, и никакое прототипирование тут не поможет.
Оригинальное решение вы предлагаете. Но не лишенное здравого смысла, а то действительно каждый смотрит со своей колокольни.
А знаете, почему большинство Front-End девелоперов или дизайнеров не переходят на использование подобных сервисов? Потому, что задачи бывают разные, а функциональное покрытие у таких онлайн-приложений, как бы там ни было, ограничено. Подписка оформлена, а функционала будет не хватать. Да и графика вся разрабатывается в граф редакторах, почему бы не рисовать ее в контексте всего темплейта. Очень интересно развитие webflow и macaw. Но сам я на продакшене, вряд ли буду пользовать подобные сервисы.
Ну не знаю. Подход о котором вы говорите (вестание страницы сразу на основании брифа) может быть эффективен только в случе если в голове у верстальщика и/или заказчика, стоящего за спиной этого верстальщика, сидит видение готового продукта. Но как быть если его нет? Получается ситуация в которой пропускается важный этап рисования задуманого «на бумаге».

Конечно можно говорить о том, что сверстаный шаблон можно менять и совершенствовать до тех пор пока он не станет удовлетворять всех мнений, но не будет ли это обходным путем вместо прямой дороги?

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

Вот на этом предложении меня аж покоробило.

В текущем положения вещей, в повальном большинстве компаний, на верстальщика возлагают большущую кипу задач. При которых специалист среднего уровня должен обладать и без того обширным спектром знаний: начиная от html,css (а порой даже php, c# и JAVA, чтоб верстать сразу в шаблонах), заканчивая знанием прикладных программ (пыхштормами, фотошопами, иллюстраторами) для того, чтобы хоть нарезать всё правильно, в случае чего, и поправить. Конечно же, такие люди должны/могут/любят интересоваться специфичными для них тематиками, чтобы быть в теме/тренде. Ну и не стоит забывать про кроссплатформенный опыт.

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

Итого: Это специалисты с разными уровнями не только знаний, но и мышления. Объем необходимых знаний просто колоссальный.

PS: Я понимаю, что был слишком груб и дизайнеров стоит делить на графику и интерфейсы, да и от верстальщиков убрать JS и прочее, однако эти пробелы в любом случае придется заполнять людьми (которые в масштабах веб-студии использоваться будут, а в масштабах какой-нибудь компании для поддержки и развития сайта будут простаивать (тут аутсорс, вся вот эта херня..)). Конечно, проблему реалистичной верстки веб-страниц это решит, однако полёта фантазии, доступного в граф. редакторах, не будет. Математически всё верно и правильно, но, как мне кажется, изначально всё ровно так и было, но из-за разреза в мышлении эти полярности исторически обросли более близкими по их тематикам областям. И не факт, что этого не произойдет вновь.
Не забывайте, что на западе Web Designer уже давно должен уметь и дизайн и верстку. Я думаю принципы разделения задачь в команде разработки еще сильно трансформируются и в русскоязычном сообществе.
Поддержу
Верстка становится все сложнее и сложнее, если раньше это делал «эникейщик», сейчас front-end имеют бОльшую нагрузку, чем раньше: планшеты, смартфоны, таблы, куча разрешений и браузеров.
Визуальные редакторы были всегда, но человека они пока не заменили.
С одной стороны верстка становится сложней, в плане поддержки большого кол-ва платформ, но с другой стороны мы получаем все больше уровней абстракции. С кучей фреймворков, типа ангуляра, бутстрапа и jquery, можно большую массу задачь решать быстро и просто.

Я считаю что фронтендеры перейдут на более сложные уровни поддержки инфраструктуры и архитектуры, в то время как визуальные редакторы, следую лучшим практикам разработки и манипулируя фреймворками заменят часть ручной работы.
Я так понимаю это статья заточена на PR продукта, хотя в некотором роде плотно затрагивает проблемы о которых я писал пару месяцев назад в "Дизайн в браузере". Прийти к единому мнению в глобальном понимании, цели не было. Я рассказал о своем видении процесса, который активно внедряю и прорабатываю. Смысл как раз в том, что в качестве инструмента использовать HTML/CSS и придерживаться методологии Абсолютно Независимых Блоков, которые мы можем переиспользовать. Сейчас большинству моих требований отвечает SourceJS в качестве основной среды и HAML + Sass + Bourbon в качестве основных инструментов. А сам подход эволюционирует, но не уходит от принципа «написания руками». Я не то что-бы против использования сторонних инструментов. Просто я вижу две очевидные проблемы:
1. Нет возможности тонкой настройки структуры разметки(html), все-таки это автогенерация, которая мягко говоря сумбурная.
2. Не удобно использовать c библиотеками(js).

Эти два казалось бы логичных фактора, отталкивают от использования. Лично для себя не вижу смысла применять сторонний инструмент, если вполне комфортно работать с разметкой и стилями руками.Это более ювелирно, чище и тоньше. А с использованием препроцессоров это дает максимум комфорта и контроля. Плюс это гораздо удобней в командной работе.

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

Мнения дизайнеров о проблеме:
  • В подобных решениях скорость работы над макетом медленнее, чем в привычном Фотошопе;
  • В принципе не используются сервисы для создания прототипов, прототипы заменяет промежуточное согласование графических макетов;
  • В графическом редакторе можно сразу создавать/редактировать графический контент веб-страниц, работая в контексте всего макета.


Мнения верстальщиков:
  • У подобных сервисов недостаточно качественно (лаконично, чисто, “ювелирно”) генерится код, в любом случае, код генерируемый автоматически будет хуже кода, написанного руками;
  • Сегодня существует слишком большой “зоопарк” устройств, и верстка должна поддерживать их все, невозможно чтобы сгенеренный код это делал;
  • В IDE есть автоматизация рутины, в конструкторах её нет;


И в одном сошлись как дизайнеры, так и верстальщики:
  • Задачи бывают разные, “руками” решить можно любую, а вот подобный инструмент рано или поздно упрется в ограничение функционала, и что-то в нём все равно нельзя будет сделать.


И все эти замечания абсолютно справедливы в реалях сегодняшнего дня — да, сегодня ни одно из существующих решений не подойдёт для полноценного и универсального использования в продакшене. Но посыл статьи был не в этом, хоть о “сегодняшнем дне” в ней и говорится очень много. Основная идея статьи — попытаться заглянуть в будущее, в тенденции и тренды, которых сейчас нет, но завтра они просто должны появится, всё идёт к этому. И это не только моё мнение, в статье уже приводились ссылки на подобные тренды, дополню ещё вот этой — 7 Crucial Web Design Trends For 2015, а именно вот этим абзацем:

2. The Decline of Web Coding

There’s always been a division of labor in web development: designers craft the look and feel, then coders step in to make it work. This process is changing as the tools for web design become smarter, more capable, and more ambitious.

...


И мой кривоватый перевод:

Второй тренд на 2015 год: “Уменьшение необходимость в ручной верстке”

В веб-разработке всегда было разделение труда: дизайнер разрабатывал внешний вид, верстальщик писал код веб-страниц. Этот процесс меняется, так как инструменты для веб-дизайна становятся быстрее и удобнее, функциональнее, амбициозней…

...


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

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

Во-первых, этот инструмент будет состоять как из визуального редактора, так и из редактора кода. Потому что полностью автоматизировать процесс верстки исключив человека невозможно — все равно останутся задачи и ситуации, когда что-то необходимо править руками, но их количество можно свести к минимуму.

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

Получается некая смесь из Фотошопа, Любимой IDE, Git’а (SVN или что кому нравится) и того же SourceJS. При этом, решение должно обладать всеми достоинствами данных продуктов — скоростью и удобством разработки внешнего вида, не хуже Фотошопа, функциональностью по автоматизации рутины, как в IDE и т.д. Но, в свою очередь, будет и лишено многих недостатков этих решений, таких как громоздкость, сложность в использовании и т.д., т.к. перечисленные решения универсальны, от того они и имеют данные недостатки, подобный же сервис заточен на веб-разработку GUI, соответственно лишен всего “ненужного”. Не будем зацикливаться на полемике, насколько сложно и невероятно это осуществить, предположим в теории, что осуществимо.

Я не говорю, что наш сервис (ВНИМАНИЕ “рекламная“ ссылка!) Ahoba.co, в своей текущей реализации даже в первом приближении соответствует данной концепции, что собственно видно и по видео. Но если посмотреть на план-разработки, в котором фич-лист разбит на этапы: визуальный редактор, редактор кода, упрощение и ускорение визуальной разработки, автоматизация рутины и т.д. То он вполне может стать подобным решением.

Напоследок хотелось бы от абстрактно-концептуальных размышлений, перейти к кратким инженерно-аналитическим изысканиям в области авто генерации css\html кода:

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

Да, всё это явно не заменит человека-инженера, но сможет упростить его работу через автоматизацию многих вещей. Как может выглядеть методология разработки веб-страниц в будущем на основе такого инструмента? Дизайнер в визуальном редакторе создает внешний вид страницы, при этом она хоть как-то сверстана, доступна для юзабилити и прочего тестирования, за несколько итераций получаем нужный результат на “живом” макете. Затем фронт-энд разработчик настраивает предпочтительные параметры автогенерации кода для продакшена, что-то правит вручную и генерит валидный, кроссбраузерный и кроссплатформенный, а главное с прозрачной и нужной структурой код.
А вы не пробовали открыть для себя и для дизайнеров Adobe Muse? Photoshop в общем-то не заточен под дизайн веб-страниц, просто исторически так сложилось. А в Muse привычные инструменты, плюс плюшки для веба (типа готовых анимаций, виджетов или генерации CSS). Например для создания лендингов он подходит идеально. Я освоил азы за 2 часа просмотра туториалов.
Adobe Muse — это одно из многих подобных решений, полный список мы уже составляли в статье — habrahabr.ru/company/ahoba/blog/240337/, получилось около 40-ка решений. Все они, как и Adobe Muse заточены под текущие (сегодняшние) методологии и жизненные циклы разработки веб-интерфейсов. Я же в этой статье и в коментариях пытаюсь сделать акцент на будущих трендах и подходах.
НЛО прилетело и опубликовало эту надпись здесь
Подход «дизайна в браузере» непременно будет активно развиваться, о чем говорит появления большого кол-ва коммерческий инструментов. Это движение уже не остановить, на данном этапе, наша задача направить новые возможности процессов разработки в нужное русло. Генерируемый код будет становится лучше, у самих инструментов будет больше возможностей для описания интерфейса.

Насчет применения подобных инструментов для более серьезных сайтов, вот пример — каркас и основную архитектуру можно задать руками, а отдельные блоки формировать в виз. редакторе. Или же из уже готовых, «разработанных руками» блоков, можно будет создвать новые странницы.

С ростом популярности модульной разработки, веб-компонентов и прочих технологий, приведенный выше пример будет встречаться все чаще. Мы ранее делали прототип интсрумента, в котором уже можно манипулировать с блоками, разработанными в ручную — youtu.be/cefy_U5NU4o?list=PL20zJcC2wnX6N6gC-n84l1vJ7mDY57U9U.
Почему в своём корпоративном блоге вы стесняетесь рекламы своих продуктов? Корпоративные блоги для того и существуют.
Как правильно выше заметили, эта статья направлена на PR, вот только не нашего продукта, а в целом — будущего подхода к жизненному циклу разработки веб-интерфейсов, отличающегося от сегодняшних реалей. Поэтому в рамках данной статьи мы «стесняемся рекламы наших продуктов», но с удовольствием «рекламируем» данный подход.

Чтобы было понятние, поясню на примере:
Сервис для проведения краудфандинговых компаний Бумстартер, ведет очень интересную рекламную политику. Они рекламируют и продвигают само понятие «краудфандинга» в русскоязычной среде, т.к. понятие пока новое и непонятно для массовой аудитории.

Примерно этим же мы и пытаемся заниматься в данной статье.
Не стесняйтесь, предупреждение «ВНИМАНИЕ “рекламная“ ссылка!» в корпоративном блоге выглядит глупо.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий