Как правильно выше заметили, эта статья направлена на PR, вот только не нашего продукта, а в целом — будущего подхода к жизненному циклу разработки веб-интерфейсов, отличающегося от сегодняшних реалей. Поэтому в рамках данной статьи мы «стесняемся рекламы наших продуктов», но с удовольствием «рекламируем» данный подход.
Чтобы было понятние, поясню на примере:
Сервис для проведения краудфандинговых компаний Бумстартер, ведет очень интересную рекламную политику. Они рекламируют и продвигают само понятие «краудфандинга» в русскоязычной среде, т.к. понятие пока новое и непонятно для массовой аудитории.
Примерно этим же мы и пытаемся заниматься в данной статье.
Adobe Muse — это одно из многих подобных решений, полный список мы уже составляли в статье — habrahabr.ru/company/ahoba/blog/240337/, получилось около 40-ка решений. Все они, как и Adobe Muse заточены под текущие (сегодняшние) методологии и жизненные циклы разработки веб-интерфейсов. Я же в этой статье и в коментариях пытаюсь сделать акцент на будущих трендах и подходах.
Очень приятно, что тематика статьи вызвала такое бурное обсуждение, значит, проблемы все-таки существуют и затрагивают многих. Попробую дополнить статью вот этим комментарием, объеденив и формально собрав весь фидбэк, который получил в этом обсуждение и в личной переписке.
Мнения дизайнеров о проблеме:
В подобных решениях скорость работы над макетом медленнее, чем в привычном Фотошопе;
В принципе не используются сервисы для создания прототипов, прототипы заменяет промежуточное согласование графических макетов;
В графическом редакторе можно сразу создавать/редактировать графический контент веб-страниц, работая в контексте всего макета.
Мнения верстальщиков:
У подобных сервисов недостаточно качественно (лаконично, чисто, “ювелирно”) генерится код, в любом случае, код генерируемый автоматически будет хуже кода, написанного руками;
Сегодня существует слишком большой “зоопарк” устройств, и верстка должна поддерживать их все, невозможно чтобы сгенеренный код это делал;
В 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 кода:
Задача создания верстки, как и создания любого кода, является также и творческой задачей. Т.е. любой код может быть написан по-разному: с использованием разных паттернов, парадигм, разных алгоритмов. И во многих случаях нельзя однозначно и объективно сказать, что какое-то конкретное решение лучше или хуже, в каждой хорошей реализации есть свои достоинства и свои недостатки. Всё в конечном счете сводится к опыту и предпочтениям разработчика. Всё это относится к написанию кода “вручную”. Всё это должно и относится и к его автогенерации. Как это реализовать? Во-первых, генерация кода должна быть гибкой и настраиваемой, это может быть реализовано через шаблоны архитектуры верстки. Выбираем подходящую к задаче архитектуру — получаем сгенерированный по ней код, для разных задач — разная архитектура. При этом обязательно должна быть функциональность создания шаблонов архитектуры вручную — это расширит сферу применения генерации, позволит разработчику использовать любимые и предпочтительные подходы. Во-вторых, при любом шаблоне архитектуры, она все равно должна быть основана на “методологии Абсолютно Независимых Блоков”, блок всегда остается независимой и гибкой сущностью, настраиваемой как угодно в рамках любой архитектуры — это даст возможность той самой “ювелирной” работы над кодом в рамках автогенерации.
Да, всё это явно не заменит человека-инженера, но сможет упростить его работу через автоматизацию многих вещей. Как может выглядеть методология разработки веб-страниц в будущем на основе такого инструмента? Дизайнер в визуальном редакторе создает внешний вид страницы, при этом она хоть как-то сверстана, доступна для юзабилити и прочего тестирования, за несколько итераций получаем нужный результат на “живом” макете. Затем фронт-энд разработчик настраивает предпочтительные параметры автогенерации кода для продакшена, что-то правит вручную и генерит валидный, кроссбраузерный и кроссплатформенный, а главное с прозрачной и нужной структурой код.
Также очень дельное замечание. На видео ранняя альфа-версия сервиса, генерация кода реализована на уровне прототипа, чтобы примерно показать, в каком направлении она будет развиваться. Согласитесь, если будет максимально оптимизированная автогенерация, оставаться динозавром нет смысла. Но на данный момент согласен — альтернативы нет. В статье рассматриваются скорее не текущие решения, а общий вектор, куда идет и когда-нибудь придет развитие.
Полностью с вами согласен. Именно поэтому один из главных реализуемых нами приоритетов, который и станет ключевой особенностью сервиса — скорость разработки в нём.
Уже сейчас для этого реализуется система линеек и направляющих, что существенно ускорит работу над макетом. Уже есть перемещение объектов с шагом в 1 и 10 пикселей (по стрелочкам и с зажатым Shift'ом). Запланированы хоткеи: выделение, перемещение, копирование, удаление группы объектов. Да и сама группировка с функцией фиксации позиционирования и отдельно оформления тоже будет. И т.д.
В итоге, надеемся, что получится не медленнее, а может даже быстрее, чем в Фотошопе. По крайней мере, делаем всё для этого возможное…
Про видео в конце статьи: вообще-то это небольшой туториал по теме, но в контексте статьи он может восприниматься как реклама, поэтому в статью вставлять видео не стал. Если вас заинтересует, можете перейти по ссылке и посмотреть на ютубе.
ПМ мониторит архитектуру разрабатываемого продукта, регулярно изучает коммиты, следит за физическим, эмоциональным состоянием программиста и прочими факторами, влияющими на производительность. Всё это позволяет условно считать, что у него есть компетенция для оценки и прогнозирования сроков. Но это для небольших задач. В случае с объемными тасками оценка производится самим программистом или в паре с ПМ'ом.
Коэффициент неточности не считали, но при первом приближении — не более 10% по статистике перенесенных дедлайнов.
+30% в основном спасают. «Ночами» дорабатывали всего 2 раза из 30 календарных дней, описанных в статье.
Оценивается эмпирически по опыту выполнения прошлых подобных задач самим исполнителем или ПМ'ом + 30% на непредвиденные обстоятельства. Если не укладывались в дедлайн — работали сверхурочно, т.к. мы сами фаундеры и максимально заинтересованы в результате.
Сейчас многое изменилось: поменялись инструменты и методология, под них были переписаны правила. Пройдет время, мы расскажем и об этом. Если будут вопросы, задавайте в комментариях, отвечу всем.
Помимо этого, мы ведем блог на сайте (http://blog.ahoba.co/) и на Спарке (http://spark.ru/startup/ahoba/blog), часть материалов этой тематике могут попасть туда. Чтобы постоянно не монитрить обновления, могу посоветовать вступить в нашу группу в одной из четырех соц. сетей (ссылки есть в блоге и на главной ahoba.co/), мы публикуем анонсы статей на разных ресурсах в них.
Пришлите в ЛС ваш е-майл, расшарю на него черновик статьи в Gogle.Docs — там есть история изменений, по которой видно, что фраза «Для разъяснения этого расскажу одну легенду…», была написана в таком виде ещё 24 сентября.
Чуть-чуть не дочитали:
>Не будем зацикливаться на достоверности этой легенды. Это просто шутка-пример о том, что трактор мог быть предком танка. Важно лишь то, что эта легенда наглядно иллюстрирует аналогию связи предок-потомок…
Очень бы хотелось подобный сервис в масштабе ВСЕЙ страны, со всеми муниципалитетами, всей иерархией всех гос. служб и единым документооборотом, от ниже стоящих к вышестоящим чиновникам и служащим всех мастей… С «прозрачным» процессом рассмотрения любого обращения от любого гражданина в любую инстанцию, и «прозрачностью» же взаимодействий между структурами… Думаю рано или поздно мы все же к этому придем, а подобные сервисы — первые шажки на этом пути…
Ммм, 9 из 13 прочтены, 2 из 9 «настольные книги», за оставшиеся, спасибо — изучу. От себя добавлю:
Ф.И. Шарков, «Основы теории коммуникации» — мат. часть, после прочтения которой намного лучше понимаешь философию, психоанализ, социологию, маркетинг и экономику.
Так же дам совет, который редко сам встречал — ПМ'ам прочитать альтернативную «евангелие» по современной теории и практики маркетинга — Джим Лисински, «ZMOT», во первых не лишне знать и понимать, как же все таки продается то что мы разрабатываем, (а это очень полезно, но мало кто ценит эту пользу!), во вторых многие эффективные маркетинговые методики можно «позаимствовать», при управлении командой. (Как это делается, понимаешь изучив теорию коммуникаций).
Я тот самый «сотрудники, в должностные обязанности которых входят сбор, классификация, распространение информации».
Соответственно занимаюсь изучением методологий обработки знаний, их практическими реализациями, анализом пользы от этого и т.д.
Не могу сказать, что почерпнул из Ваших статей что то концептуально новое, для себя, но порадовался, что не одного меня задевают подобные вопросы, (а такое чувство иногда возникает).
Чтобы было понятние, поясню на примере:
Сервис для проведения краудфандинговых компаний Бумстартер, ведет очень интересную рекламную политику. Они рекламируют и продвигают само понятие «краудфандинга» в русскоязычной среде, т.к. понятие пока новое и непонятно для массовой аудитории.
Примерно этим же мы и пытаемся заниматься в данной статье.
Мнения дизайнеров о проблеме:
Мнения верстальщиков:
И в одном сошлись как дизайнеры, так и верстальщики:
И все эти замечания абсолютно справедливы в реалях сегодняшнего дня — да, сегодня ни одно из существующих решений не подойдёт для полноценного и универсального использования в продакшене. Но посыл статьи был не в этом, хоть о “сегодняшнем дне” в ней и говорится очень много. Основная идея статьи — попытаться заглянуть в будущее, в тенденции и тренды, которых сейчас нет, но завтра они просто должны появится, всё идёт к этому. И это не только моё мнение, в статье уже приводились ссылки на подобные тренды, дополню ещё вот этой — 7 Crucial Web Design Trends For 2015, а именно вот этим абзацем:
И мой кривоватый перевод:
Нет, ну правда, все выше написанные замечания по делу, но практически каждое из них — “непаханое поле” для автоматизации. Например, та же “ручная поддержка зоопарка устройств, при верстке”, если хотя бы эту проблему суметь решить, автоматизировав процесс, сколько бы человеко-часов, а соответственно и денег, можно было бы экономить? Да, визуальные редакторы были всегда, и ещё не разу не смогли заменить человека. Да, верстка и фронт-энд становятся все сложнее и сложнее, что отнюдь не упрощает задачу по автоматизации их создания. Но и уровень ИТ-инженеров не стоит на месте. Сегодня мы беремся за решения задач, на которые даже не смотрели ещё каких-то двадцать лет назад.
Представьте, что всё же появится продукт, полностью закрывающий все замечания, как верстальщиков, так и дизайнеров. Не будем говорить о том, что это сегодня невозможно, попробуем заглянуть в будущее, ориентируясь на предсказанные тренды. Какова будет концепция этого продукта?
Во-первых, этот инструмент будет состоять как из визуального редактора, так и из редактора кода. Потому что полностью автоматизировать процесс верстки исключив человека невозможно — все равно останутся задачи и ситуации, когда что-то необходимо править руками, но их количество можно свести к минимуму.
Во-вторых, да, он будет основан на “методологии Абсолютно Независимых Блоков”, которые многократно и независимо можно переиспользовать. Причем как в визуальном редакторе, так и в редакторе кода, что будет дополнено инструментами документации кода, контроля версий и т.д.
Получается некая смесь из Фотошопа, Любимой IDE, Git’а (SVN или что кому нравится) и того же SourceJS. При этом, решение должно обладать всеми достоинствами данных продуктов — скоростью и удобством разработки внешнего вида, не хуже Фотошопа, функциональностью по автоматизации рутины, как в IDE и т.д. Но, в свою очередь, будет и лишено многих недостатков этих решений, таких как громоздкость, сложность в использовании и т.д., т.к. перечисленные решения универсальны, от того они и имеют данные недостатки, подобный же сервис заточен на веб-разработку GUI, соответственно лишен всего “ненужного”. Не будем зацикливаться на полемике, насколько сложно и невероятно это осуществить, предположим в теории, что осуществимо.
Я не говорю, что наш сервис (ВНИМАНИЕ “рекламная“ ссылка!) Ahoba.co, в своей текущей реализации даже в первом приближении соответствует данной концепции, что собственно видно и по видео. Но если посмотреть на план-разработки, в котором фич-лист разбит на этапы: визуальный редактор, редактор кода, упрощение и ускорение визуальной разработки, автоматизация рутины и т.д. То он вполне может стать подобным решением.
Напоследок хотелось бы от абстрактно-концептуальных размышлений, перейти к кратким инженерно-аналитическим изысканиям в области авто генерации css\html кода:
Задача создания верстки, как и создания любого кода, является также и творческой задачей. Т.е. любой код может быть написан по-разному: с использованием разных паттернов, парадигм, разных алгоритмов. И во многих случаях нельзя однозначно и объективно сказать, что какое-то конкретное решение лучше или хуже, в каждой хорошей реализации есть свои достоинства и свои недостатки. Всё в конечном счете сводится к опыту и предпочтениям разработчика. Всё это относится к написанию кода “вручную”. Всё это должно и относится и к его автогенерации. Как это реализовать? Во-первых, генерация кода должна быть гибкой и настраиваемой, это может быть реализовано через шаблоны архитектуры верстки. Выбираем подходящую к задаче архитектуру — получаем сгенерированный по ней код, для разных задач — разная архитектура. При этом обязательно должна быть функциональность создания шаблонов архитектуры вручную — это расширит сферу применения генерации, позволит разработчику использовать любимые и предпочтительные подходы. Во-вторых, при любом шаблоне архитектуры, она все равно должна быть основана на “методологии Абсолютно Независимых Блоков”, блок всегда остается независимой и гибкой сущностью, настраиваемой как угодно в рамках любой архитектуры — это даст возможность той самой “ювелирной” работы над кодом в рамках автогенерации.
Да, всё это явно не заменит человека-инженера, но сможет упростить его работу через автоматизацию многих вещей. Как может выглядеть методология разработки веб-страниц в будущем на основе такого инструмента? Дизайнер в визуальном редакторе создает внешний вид страницы, при этом она хоть как-то сверстана, доступна для юзабилити и прочего тестирования, за несколько итераций получаем нужный результат на “живом” макете. Затем фронт-энд разработчик настраивает предпочтительные параметры автогенерации кода для продакшена, что-то правит вручную и генерит валидный, кроссбраузерный и кроссплатформенный, а главное с прозрачной и нужной структурой код.
Уже сейчас для этого реализуется система линеек и направляющих, что существенно ускорит работу над макетом. Уже есть перемещение объектов с шагом в 1 и 10 пикселей (по стрелочкам и с зажатым Shift'ом). Запланированы хоткеи: выделение, перемещение, копирование, удаление группы объектов. Да и сама группировка с функцией фиксации позиционирования и отдельно оформления тоже будет. И т.д.
В итоге, надеемся, что получится не медленнее, а может даже быстрее, чем в Фотошопе. По крайней мере, делаем всё для этого возможное…
Коэффициент неточности не считали, но при первом приближении — не более 10% по статистике перенесенных дедлайнов.
+30% в основном спасают. «Ночами» дорабатывали всего 2 раза из 30 календарных дней, описанных в статье.
Помимо этого, мы ведем блог на сайте (http://blog.ahoba.co/) и на Спарке (http://spark.ru/startup/ahoba/blog), часть материалов этой тематике могут попасть туда. Чтобы постоянно не монитрить обновления, могу посоветовать вступить в нашу группу в одной из четырех соц. сетей (ссылки есть в блоге и на главной ahoba.co/), мы публикуем анонсы статей на разных ресурсах в них.
Спасибо за пожелания.
Пришлите в ЛС ваш е-майл, расшарю на него черновик статьи в Gogle.Docs — там есть история изменений, по которой видно, что фраза «Для разъяснения этого расскажу одну легенду…», была написана в таком виде ещё 24 сентября.
>Для разъяснения этого расскажу одну легенду…
Чтобы уже все вопросы отпали, поменяю на:
Для разъяснения этого расскажу одну легенду, не соответствующую действительности…
>Не будем зацикливаться на достоверности этой легенды. Это просто шутка-пример о том, что трактор мог быть предком танка. Важно лишь то, что эта легенда наглядно иллюстрирует аналогию связи предок-потомок…
Ф.И. Шарков, «Основы теории коммуникации» — мат. часть, после прочтения которой намного лучше понимаешь философию, психоанализ, социологию, маркетинг и экономику.
Так же дам совет, который редко сам встречал — ПМ'ам прочитать альтернативную «евангелие» по современной теории и практики маркетинга — Джим Лисински, «ZMOT», во первых не лишне знать и понимать, как же все таки продается то что мы разрабатываем, (а это очень полезно, но мало кто ценит эту пользу!), во вторых многие эффективные маркетинговые методики можно «позаимствовать», при управлении командой. (Как это делается, понимаешь изучив теорию коммуникаций).
Соответственно занимаюсь изучением методологий обработки знаний, их практическими реализациями, анализом пользы от этого и т.д.
Не могу сказать, что почерпнул из Ваших статей что то концептуально новое, для себя, но порадовался, что не одного меня задевают подобные вопросы, (а такое чувство иногда возникает).