Внешняя разработка через призму зрения
С первого взгляда Webflow заставил меня вспомнить старое приложение Adobe Dreamweaver. Основная цель была прежней: инструмент, который поможет вам создать веб-сайт, просто перетаскивая элементы на холст без написания кода. Сначала меня это напугало, потому что Dreamweaver был основной причиной, по которой я стал разработчиком и начал писать свой код. Сгенерированный HTML и стиль были ужасными и беспорядочными. Я помню, как мои элементы летали в разных местах в зависимости от того, какой браузер вы использовали. После этого я сосредоточился на изучении веб-стандартов и написании кода.
После нескольких часов работы с Webflow мы с удивлением увидели, как Webflow прилагает усилия к реальной разработке и насколько чистым является сгенерированный код. Давайте посмотрим на это подробнее.
Код интерфейса VS: сохранение одной и той же мысленной модели является ключевым моментом
Первая проблема, с которой столкнется разработчик переднего плана, использующий Webflow, — понять связи между интерфейсом и тем, что вы обычно делаете с кодом, и как вы можете применить ту же ментальную модель, которую разработчик переднего плана использует для разработки.
В Webflow у нас есть две отдельные основные панели, одна для стилей и взаимодействий, а другая для HTML и структуры. Когда разработчики интерфейса работают с кодом, мы разделяем HTML, CSS (стили) и Javascript (взаимодействия). Эта работа упрощает применение той же ментальной модели и говорит о том, как Webflow принимает во внимание реальную разработку.
Здесь мы достигли сильной точки. Разработка — это скорее способ мышления, чем куча кода, и Webflow позволяет вам начать с этой точки.
Классы, повторно используемые стили и соглашение об именах
Мне нравится, как Webflow использует классы для ссылки на элементы HTML. Это позволяет вам применять соглашение об именовании классов БЭМ, хорошую практику, которой мы, как разработчики интерфейсов, следуем в качестве руководства, поскольку оно позволяет вам семантически выражать то, что делает ваш компонент, просто следуя соглашению об именовании.
Например, если у нас есть элемент div с классом под названием «.block», и у нас есть дочерний элемент внутри этого div, который является текстом, мы можем добавить имя класса с именем «.block__description», указывающее, что это дочерний элемент этого компонента. В другом контексте, если мы хотим указать модификацию элемента, мы можем добавить класс модификатора, например, «кнопка .block__ — отправить».
Приятно знать, что Webflow также рекомендует следовать этой практике.
Компоненты
Точно так же, как интерфейс использует компоненты для создания веб-сайта, Webflow поддерживает повторное использование компонентов. Таким образом, вместо того, чтобы создавать нижний колонтитул или заголовок для каждой страницы, мы можем повторно использовать их как компонент. Как разработчик, мне определенно не хватает некоторой логики для компонентов. Например, у нас нет атрибутов для определения конкретной версии компонента (заголовок с инвертированными цветами). Для этого нам нужно продублировать компонент, разъединить его, а затем создать еще один новый компонент для этой версии.
Взаимодействия
Невероятно легко управлять положением мыши, эффектами прокрутки и взаимодействием с элементами, когда они входят или выходят из области просмотра. Создавать эффекты параллакса было очень просто. Я думаю, что это очень приятный опыт для разработчика, потому что у нас обычно нет такой визуальной поддержки, когда мы создаем эти эффекты.
С другой стороны, я упустил логические условия взаимодействия. Когда вы смешиваете взаимодействия, чтобы задать различное поведение для элемента, это становится беспорядочным, и вам может потребоваться собственный код для достижения того, чего вы хотите. Позвольте мне объяснить на практическом случае, от которого я пострадал:
Я хотел, чтобы липкий заголовок появлялся только тогда, когда пользователь прокручивает назад, но когда позиция прокрутки приближается к верхней части, я хотел, чтобы липкая полоса исчезала. Поэтому я добавил триггер к элементу вверху с таким поведением, установив непрозрачность 0 для липкого заголовка. Иногда это работало, а иногда нет, почему? Я заметил, что взаимодействие с прокруткой назад перекрывает взаимодействие с исчезновением, и я не могу установить условие для установки этого логического, как я могу легко сделать в коде с оператором if — else.
Простое управление CMS
Я обнаружил, что CMS очень проста в управлении, вам не нужно возиться с базами данных и техническими вещами. Я хотел создать систему блогов с тегами категорий, и это было очень легко сделать. Вам просто нужно создать список коллекций, а затем связать его с нужной коллекцией CMS.
С другой стороны, при работе с CMS меня разочаровало, что нельзя добавить взаимодействия между элементами одной коллекции. Вы не можете добиться, например, поэтапной анимации плавного появления без написания кода. И для написания этого кода вам придется добавить собственный наблюдатель пересечений, и мне не очень удобно смешивать собственный код Javascript и собственный Webflow. Вы знаете, как разработчику безумно определять две разные вещи для одной и той же функциональности. Часть ментальной модели программирования — помнить о дублирующемся коде. Я чувствую, что Webflow может улучшить то, как мы можем смешивать пользовательский код с собственными функциями Webflow, не запутываясь. Кроме того, мне не понравилось, что вы должны включать пользовательский код, покидая представление панелей.
Что мне нравится в работе с Webflow
- Это отличный вариант для создания быстрых, несложных и очень наглядных веб-сайтов, которым не нужно возиться с внутренней разработкой, хостингом, серверами или техническими аспектами.
- Отлично подходит для быстрого добавления взаимодействий без программирования — например, для создания пользовательского курсора, управления наблюдателем пересечения, создания эффектов прокрутки и т. д.
- Редактор и CMS хороши
- За этим стоит хорошее сообщество
- Поддержка клиентов быстрая
- Сгенерированный код очень чистый и хорошо структурированный
- Вам не нужно беспокоиться о внутренних вещах, и здорово оставаться сосредоточенным на пользовательском интерфейсе и проявлять творческий подход во внешнем интерфейсе.
Что мне не хватает при работе с Webflow
- Вы не можете добавлять взаимодействия с задержкой для элементов в коллекции CMS. Например, вы не можете создавать анимацию с задержкой.
- Логические условия взаимодействия
- Организация коллекций взаимодействий должна быть улучшена. Если у вас много взаимодействий, результатом будет большой список, и работать с ним может быть когнитивно сложно. Нет сортировки или фильтрации по имени или порядку… как насчет создания папок для организации работы?
- Планы трудно понять, и перенос сайтов может оказаться большим путешествием.
- Параметр восстановления резервной копии из представления конструктора. Здесь у нас нет git-репозитория, чтобы контролировать, что изменилось. Мне не очень удобно сохранять Webflow каждый раз, когда вы вносите изменения. Для меня Ctrl+Z недостаточно, и мне не хватает большего контроля над внесенными вами изменениями.
- Иногда Webflow глючит, и вы не знаете, виноваты вы или нет.
- Мне не хватало гибкости в HTML. У вас нет блока кнопок, как блока ссылок. Если вы хотите добиться творческого наведения для кнопки отправки, вы должны проявить творческий подход. В моем случае я создал поддельную кнопку с элементом div, а затем поместил кнопку отправки с нулевой непрозрачностью, чтобы добиться такого эффекта:
В заключение, является ли фронтенд-разработчик подходящим профилем для создания веб-сайтов в Webflow?
Разработчики будут на шаг впереди дизайнеров при изучении Webflow. Основные концепции Webflow одинаковы с точки зрения разработки, поэтому интерфейсу проще работать с интерфейсом, который знает, как создать веб-сайт со всеми знаниями CSS, HTML и Javascript. Я думаю, что для дизайнера, который знает нулевой код, эта часть может быть очень сложной. Я думаю, что Webflow больше подходит для визуального программирования, чем для проектирования без знания кода.
Кроме того, разработчику, который знает, как решать и устранять проблемы, будет проще, когда происходят странные вещи — например, почему сайт не выглядит одинаково в Safari и Chrome? А иногда для достижения именно того, что нам нужно, потребуется дополнительный код.
Так что в целом да. Если вы Front-end разработчик, дерзайте.
Примите Webflow 😀.
Автор: Марина Галлардо, ведущий разработчик внешнего интерфейса Far Co
Для получения дополнительной информации или уточнения по любому вопросу, пожалуйста, свяжитесь с Мариной по адресу [email protected].
…………………
Far Co — это студия дизайнеров и разработчиков, которые проектируют и создают цифровые продукты, способствующие развитию бизнеса. Мы сотрудничаем с клиентами, чтобы переосмыслить, создать и масштабировать их продукты — веб-сайт, мобильное приложение или сенсорный экран — с четкими бизнес-целями, связанными с привлечением потенциальных клиентов, конверсией и монетизацией каждой идеи.
