Дизайн vs. Верстка?

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

    Настало время наконец-то найти ответы на два главных вопроса: “Кто виноват?” и “Что делать?” в вечной борьбе дизайна и верстки…



    Типовой жизненный цикл разработки веб-интерфейсов


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

    Этап первый: Создание формальных требований на разрабатываемый интерфейс. Конечный результат этого этапа — бриф или техническое задание, где описано, что должно быть на макете, и как это будет реализовано. Занимаются этим люди с проектными ролями: бизнес-аналитик, технический писатель;

    Этап второй: Разработка графического дизайн-макета по брифу или ТЗ. Данную работу выполняет дизайнер (веб-дизайнер, дизайнер GUI);

    Этап третий: Верстка интерфейса (создание html\css\JS кода) по графическому дизайн-макету. Над версткой работает верстальщик (фронтенд разработчик, веб-разработчик).

    Ограничиться базовыми этапами и получить высококлассный результат можно, пожалуй, только в “сферических условиях в вакууме”. На практике на каждом этапе возникает ряд проблем, решать которые приходится, вводя подэтапы и усложняя жизненный цикл разработки интерфейса.

    Примерами проблем и возникающих по их вине подэтапов могут быть:
    • Отсутствие общего видения или непонимание предметной области — ограничиться текстовым описанием в брифе или ТЗ не получится. Необходимо будет создать несколько прототипов, провести дополнительные исследования.
    • Приятно выглядящий интерфейс может оказаться неудобным в использовании. Чтобы этого избежать приходится привлекать к работе юзабилити-специалиста и проводить дополнительную экспертизу на предмет удобства использования и т.д.




    Подробнее о возникающих проблемах и способах их решения поговорим ниже, начав с вопроса объективности оценки качества дизайн-макетов.

    Проблема формальной оценки дизайна


    Под разработкой дизайна веб-интерфейсов подразумевают работу по проектированию взаимодействия и оформлению внешнего вида веб-страниц. Внешний вид удобно передать в графическом дизайн-макете. Т.е. работа над дизайном сводится к созданию макета.

    Оценка макета, по большому счету, субъективна. Часто строится на таких эпитетах, как красиво, нравится, приятный, аккуратный, и их вариантами с приставкой “не”… Качество макета оценивается по личным предпочтениям. Встает вопрос: а можно ли вообще формально оценить макет по субъективным критериям? Можно. И самый действенный способ — тестирование на фокус группе: набирается группа людей из целевой аудитории, для которой разрабатывается макет, проводится его демонстрация, после чего участники исследования заполняют анкеты-опросники, выставляя оценки исходя из своего личного мнения по этим субъективным параметрам. Среднестатистическое значение — адекватная оценка качества макета.

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

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

    По этим принципам в начале эпохи домашних компьютеров создавались решения от Apple, превратившие в произведение дизайнерского искусства эти самые ПК, в противовес “квадратно-практичному” внешнему виду продуктов конкурентов. Потребители сами не догадывались, что им понравится тот факт, что такая утилитарная вещь, как компьютер, может быть стильным дизайнерским решением. Но увидев реализацию, созданную дизайнерами, не считавшимися с мнением потребителя, все же положительно оценили её. Впрочем, это другая история, вернемся к разработке внешнего вида веб-страниц…

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

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

    Формальная оценка качества дизайн-макета возможна, но на деле редко осуществима. Любая индивидуальная оценка — субъективна, и это помимо прочих проблем разработки веб-интерфейсов…



    Несоответствие ощущений от графического макета и сверстанной веб-страницы


    Проблема, озвученная в подзаголовке, хорошо известна в среде веб-дизайнеров:
    Как бы качественно и детально ни был отрисован макет, он остается графическим изображением, иногда его ещё называют “мертвым” макетом. Даже если вы разрабатываете дизайн веб-страницы, где нет динамических элементов (раскрывающихся меню, меняющихся по клику теней и т.д.), все равно ваш макет по ощущениям отличается от конечной, сверстанной страницы (даже на статике можно выделить текст, проскроллить и прочее).

    Касается эта проблема и удобства использования. Частично юзабилити-экспертизу можно провести и по графическому макету (оценив расположение и компоновку элементов и т.д.), но полноценно понять, насколько удобным оказался интерфейс, выявить все подводные камни в работе с ним, можно только по конечной, готовой веб-странице.

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

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

    Как можно было бы избежать всех этих проблем при разработке веб-интерфейсов


    Что мы имеем в итоге? Озлобленных дизайнеров, рисующих N’ую версию макета и правомерно заявляющих: “нужно более формально задавать требования к макету”. Не менее раздраженных верстальщиков, переверстывающих страницу в M’ый раз. Дополняют эту картину растянувшиеся сроки, проваленные дедлайны, превышенные бюджеты и извечные вопросы “Кто виноват?” и “Что делать?”



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

    Этап первый: Подготовка контента;

    Этап второй: Создание краткого брифа с описанием функциональности и формальных требований к разрабатываемому интерфейсу;

    Этап третий: Быстрая разработка интерфейса в тех условиях, где он будет использоваться (прямо в браузере), сразу верстая его как готовую веб-страницу, с непрерывной экспертной и юзабилити оценкой.

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

    Об этом говорилось в статье, ссылку на которую мы дали в начале поста (http://habrahabr.ru/post/238485/), но продублирую ещё раз сюда:
    • На питерском WSD большая часть докладов была посвящена этой теме — http://webstandardsdays.ru/2014/06/28/;
    • Об этом говорилось в докладе Антона Виноградова из Альфа-лаб на BEMup (https://tech.yandex.ru/events/bemup/6-september-2014/talks/2189/), где он рассматривал тему на примере верстки приложения Яндекс.Такси;
    • Доклад Ильи Пухальского на Rest in PS (https://vimeo.com/85995812) также наглядно разъяснил аналогичную проблему.

    В тексте той статьи и в комментариях к ней был высказан, а главное — опровергнут тезис, как реализовать данный подход: “Необходимо, чтобы дизайнер был и верстальщиком, и разрабатывал интерфейс сразу как готовую верстку”.

    Там же, в комментариях были озвучены и другие примеры, говорящие за актуальность описанного подхода — это появившиеся в недавнем времени специализированные продукты. Во-первых, это решения для быстрого создания прототипов веб-страниц, такие как: www.axure.com, http://froont.com. Во-вторых, это программы и сервисы нового поколения, где при визуальной разработке макета, сразу генерится готовая верстка (и в отличие от похожих продуктов “старого поколения”, эти решения генерят чистый и лаконичный код, как будто его писал высококлассный верстальщик): http://macaw.co, https://webflow.com.

    Продукты для создания прототипов хороши тем, что можно быстро получить визуальный результат, но о лаконичной и чистой верстке, а тем более о полноценных интерфейсах, созданных в них, речи не идет. Решения, которые генерируют качественный код, нельзя назвать простыми, и быстро работать в них не получится. Порой время работы с ними, напротив, соизмеримо или даже дольше, нежели в случае, когда сперва нужно отрисовать графический макет, а затем “вручную” его сверстать. При этом ни в тех, ни в других нет возможности работать над макетом в тех условиях, в которых он будет использоваться (т.е. прямо в браузере, с отсутствующими рабочими элементами редактора). Да и функция автосохранения и хостинга проектов, дающая непрерывный доступ к промежуточному результату третьим лицам (для оценки качества, юзабилити-экспертизы и т.д.), имеется далеко не у всех…

    Когда появится решение, лишенное всех этих недостатков и способное полноценно реализовать предложенный жизненный цикл разработки веб-интерфейсов, остается лишь вопросом времени. Все тенденции ведут именно к такому продукту.

    Если вас заинтересовала проблематика, описанная в статье, и её решение, в качестве бонуса предлагаем посмотреть вот это короткое видео — http://www.youtube.com/watch?v=nIOVU9_KRKA

    Кирилл,
    руководитель проекта Mockup editor SletchBuilder
    В соавторстве с нашим дизайнером Сергеем Sevenvampire и веб-разработчиком Антоном skrutty.
    SketchBuilder
    Company
    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 28

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


                                Мнения верстальщиков:
                                • У подобных сервисов недостаточно качественно (лаконично, чисто, “ювелирно”) генерится код, в любом случае, код генерируемый автоматически будет хуже кода, написанного руками;
                                • Сегодня существует слишком большой “зоопарк” устройств, и верстка должна поддерживать их все, невозможно чтобы сгенеренный код это делал;
                                • В 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 кода:

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

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

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

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

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

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

                                    Only users with full accounts can post comments. Log in, please.