Мы часто говорим о таких несомненно важных вещах, как оптимизация, сложные интеграции и архитектура. Это действительно основа, без которой ничего не работает. Однако стоит затронуть тему менее «компьютерную» и более приземленную – ту самую, что нередко становится причиной нестандартных требований к интерфейсу.
Речь пойдет о впечатлении. Ведь именно его формируют люди – те, кто будет ежедневно по восемь часов работать с вашим решением. Именно они «чувствуют» 1С через анимации, кнопки и тени. Именно они испытывают тревогу, наводя курсор на красную кнопку «Удалить», и облегчение, когда при закрытии месяца все загорается зеленым.
И нередко именно эти люди, которые чувствуют, а не только анализируют, принимают решение о том, нужен ли им ваш проект или продукт, стоит ли покупать его или нет.
Мы рассмотрим, как с помощью 1С:Элемента можно удовлетворять требованиям людей, которые «чувствуют».
Я работаю с 1С всего три года, но уже успел плотно связать себя с 1С:Элементом: разрабатывал витрины, личные кабинеты, обучающие платформы и множество других форматов. Преподаю 1С:Элемент специалистам по 1С, чтобы они могли расширять свои компетенции. С технологией сталкивался в самых разных форматах и сценариях, поэтому считаю, что могу делиться своим опытом.
Эта статья ориентирована на практиков. Я постараюсь подсветить типичные проблемы и ситуации, с которыми многие уже сталкивались, и показать решения, которые помогут в работе.
Эволюция пользовательского опыта в экосистеме 1С
Поскольку речь идет об интерфейсах, начнем с базовых вещей.
Когда мы говорим о платформе и экосистеме 1С, мы традиционно имеем дело с бизнес-приложениями и бизнес-пользователями.
Бизнес-приложения создаются под конкретные рабочие задачи. Их интерфейсы ориентированы на человека, который сидит за компьютером в рабочие часы и решает прикладные задачи. Ему не нужны развлечения, анимации и «красивые кнопочки» – главное, чтобы интерфейс помогал быстро и удобно выполнить работу.
Поэтому не стоит ожидать, что Управление торговлей когда-нибудь станет похоже на интерфейс любимого приложения доставки еды. Это просто разные миры, решающие разные задачи.
Разработчики 1С традиционно жили в этой вселенной – создавали бизнес-приложения для бизнес-пользователей, где не требовалось визуальных украшений и нестандартных решений. Казалось, что так будет всегда. Но будущее уже наступило.
Появились мобильная платформа, веб-клиент, «воздушный» интерфейс 8.5, на который со временем перейдут все конфигурации. Расширились способы взаимодействия конечных пользователей с 1С – через систему взаимодействия, Telegram, Web Apps и другие форматы.
В результате пользовательский опыт стал размываться. Теперь мы не всегда можем точно сказать, кто наш конечный пользователь – классический бизнес-пользователь или кто-то, кто ближе к потребительской аудитории.
Экосистема 1С сегодня охватывает настолько широкий спектр сценариев, что сама платформа начинает выходить за пределы привычных бизнес-приложений и заходить в область потребительских решений.
Когда бухгалтер работает в 1С:ERP – все понятно: есть бизнес-приложение и бизнес-пользователь, замкнутый рабочий процесс. Но если, например, через веб-клиент опубликовать витрину для партнера, чтобы он самостоятельно размещал заказы клиентов – это все еще бизнес-приложение? А если расширить доступ и добавить другие сценарии? В таком случае платформа 1С:ERP начинает решать уже иные задачи, ближе к пользовательским. Опыт взаимодействия размывается.
И в какой-то момент, обсуждая проект на 1С:Элементе с заказчиком, где все идет отлично, и low-code-возможности закрывают 90% потребностей, вы внезапно услышите требования на оставшиеся 10% – и эти требования будут касаться интерфейса. Знакомая ситуация?
Пока команда судорожно ищет, как сделать, чтобы при наведении на кнопку «взмывали бабочки и взрывались взрывы», вы пытаетесь разобраться, что такое «брендбук». Какими бы иррациональными ни казались эти запросы с инженерной точки зрения, иногда именно они определяют судьбу проекта. Заказчик может отказаться от решения и перейти, например, на JavaScript.
И если вы привыкли работать с классическими бизнес-приложениями, к такому повороту вас, скорее всего, не готовили. Ведь теперь значительная часть бюджета – условно 80% – может уйти на реализацию нестандартных требований к интерфейсу.
Именно поэтому стоит обсудить эту тему. Я сталкивался с подобными требованиями и нашел решения, которыми хочу поделиться.
Возможности 1С:Предприятие Элемент для кастомизации интерфейсов
Платформа 1С:Предприятие Элемент изначально ориентирована на работу в облаке. Она предоставляет широкие возможности для кастомизации интерфейса и позволяет выносить рабочие места в отдельные сервисы, при этом получать данные напрямую из основной базы 1С. Например, встроенные типы, такие как произвольная карточка и произвольная строка списка, дают возможность создавать интерфейсы, которые стандартная «восьмерка» – даже версия 8.5 – пока не поддерживает, особенно в части произвольных списков.
Произвольно-клиентское приложение дает гибкость в верстке, сохраняя при этом использование стандартных компонентов.
Кстати, небольшой практический момент: если при разработке на Элементе вы добавляете фоновое изображение, оно слегка осветляется. Попробуйте вставить такую картинку на темный фон – иногда получается очень эффектно и гармонично с точки зрения дизайна.
Технология 1С:Предприятие Элемент закрывает множество сценариев по автоматизации рабочих мест. Главное ее преимущество – возможность адаптировать интерфейс под конкретный опыт пользователя.
Можно, например, создать отдельный сервис на Элементе для ERP-системы, учитывающий специфику рабочего места сотрудника производства, и рядом – сервис с интерфейсом, удобным для менеджера по продажам. Платформа изначально заточена под такую гибкость.
Однако даже при всем этом функционале бывают ситуации, когда стандартных возможностей все же недостаточно.
Работа с нестандартными требованиями: переговоры и альтернативы
Иногда заказчик заявляет, что стандартных компонентов 1С:Элемента недостаточно, и просит реализовать часть интерфейсов на React.
Прежде чем соглашаться и добавлять в проект еще одну технологическую цепочку, стоит остановиться и разобраться, что стоит за этим требованием.
Попробуйте сыграть роль психолога: выясните, действительно ли это потребность в нестандартных интерфейсах. Часто за такими запросами скрывается простая бизнес-функция, которую заказчик по какой-то причине «упаковал» в необычную кнопку.
Задайте уточняющий вопрос: почему, например, кнопка должна быть фиолетовой?
Если ответ звучит так: «чтобы менеджер принимал решение на 20% быстрее», – значит, речь идет не об интерфейсе, а о бизнес-функции.
В таких случаях полезно «поиграть в финансиста» и объяснить заказчику, что такое совокупная стоимость владения продуктом. Покажите, что поддержка React в будущем может оказаться дороже, чем реализация решения на стандартных инструментах 1С. Иногда после этого заказчик соглашается остаться в рамках платформы.
Предложите альтернативу: например, сделать 90% интерфейсов на 1С:Элементе, а оставшиеся 10% временно не реализовывать. На этапе переговоров многие нестандартные требования трансформируются в более стандартные и реализуемые решения, которые можно сделать быстрее, дешевле и поддерживать силами 1С-разработчиков.
Однако не всегда удается договориться. Бывает, что нестандартные требования действительно продиктованы бизнес-функцией – и без них продукт не сможет работать.
Простой пример: Kanban-доска без drag-and-drop. На текущий момент в Элементе (в облачной версии 8.0.5) drag-and-drop отсутствует, но для ряда задач он критически необходим.
Да, у технологии есть ограничения – она новая и активно развивается. Ключевое слово – «пока что». То, что сегодня выглядит как недостаток, завтра может быть реализовано вендором и превратится в преимущество: вам не придется поддерживать собственную реализацию, достаточно будет просто обновить версию технологии.
Но если ждать невозможно, а заказчик буквально стоит у двери с деньгами и говорит: «либо делаем сейчас, либо идем к другим», – приходится искать решения здесь и сейчас.
Поиск решений: интеграция современных веб-подходов
Поэтому я начал искать инструменты и подходы, которые позволили бы реализовывать интерфейсы в более расширенном виде – с учетом опыта современной веб-разработки.
Сразу поставил перед собой задачу: по возможности исключить «красные квадратики» – зоны, где придется привлекать специалистов вне стека 1С, например JavaScript- или React-разработчиков.
Почему это важно? Помимо дополнительных расходов на оплату их труда, возникает организационная сложность. Если, к примеру, вы добавили в заказ клиента новый реквизит, его нужно не только учесть в бэк-офисе на 1С:Элементе, но и отобразить на фронтенде. Для этого придется искать отдельного специалиста, который нарисует форму взаимодействия.
В идеале хочется, чтобы все выглядело как на правой схеме – реализовано средствами 1С:Элемента или полностью на самом Элементе, без привлечения внешних фреймворков. Такие кейсы уже есть: многие проекты успешно создаются только на Элементе, минуя 1С.
После этого я задумался, как двигаться дальше и какие решения можно применить. И, признаюсь, не без любопытства задал коллегам вопрос: кто уже пробовал использовать искусственный интеллект в своей работе? Кто использует искусственный интеллект для генерации фронтенда? Единицы. А ведь в остальном IT-мире многие задачи, которые мы пока выполняем вручную, уже давно решаются автоматически. Именно поэтому мне хотелось, чтобы мое решение хоть немного продвинуло нас, специалистов по 1С, в сторону генеративного ИИ.
От него уже никуда не уйти. Отношение может быть разным – кто-то воспринимает ИИ с энтузиазмом, кто-то с настороженностью, – но факт остается фактом: генеративный искусственный интеллект прекрасно справляется с задачами фронтенд-разработки.
Он делает это быстро, почти без ошибок, заменяя и дизайнера, и верстальщика. Автоматически создает адаптивную верстку, темную тему, подбирает стили и цвета. Достаточно просто пообщаться с моделью – и готова полноценная страница, разработка которой раньше стоила бы миллионы рублей.
Поэтому я убежден, что HTML и CSS должны оставаться частью стека, особенно если мы говорим о современном подходе к интерфейсам в экосистеме 1С. Хотелось бы, чтобы JavaScript в решении было по минимуму, а основа строилась на HTML и CSS.
Казалось бы, все просто: используем HTML-контейнер, генерируем разметку и стили, обрабатываем действия пользователя – как это обычно делается в платформе.
Однако есть проблема. В 1С:Элементе контейнер HTML не поддерживает обработку событий при нажатии – ни в каком варианте. Текущая реализация не позволяет получить обратную связь о том, что происходит внутри контейнера.
Например, через HTML-контейнер можно отобразить отчет, визуализировать диаграмму или встроить Яндекс.Карты – все это работает отлично. Но если нужно построить полноценный интерфейс, где требуется реагировать на действия пользователя, возникает ограничение: платформа не возвращает события изнутри контейнера.
Я задумался, как можно обойти эту проблему – и ушел в совершенно другом направлении.
Знакомство с htmx: программирование через HTML
Я решил изучить, как подобные задачи решаются в современной веб-разработке, и познакомился с новой парадигмой, которая называется htmx. Это небольшая JavaScript-библиотека, которая встраивается прямо в HTML-страницу и позволяет… программировать с помощью HTML.
Помните шутку: «Какие языки программирования ты знаешь? – HTML, C#, CSS»? Так вот, теперь это уже не шутка. HTMX позволяет задавать поведение элементов через атрибуты тегов: что произойдет при их обновлении, по какому адресу получить нужные данные и куда встроить возвращенный фрагмент страницы.
Разберем, что здесь происходит. У нас есть кнопка. Без htmx пришлось бы писать JavaScript, вешать слушатель событий и обрабатывать нажатие.
С htmx все проще: при нажатии на кнопку выполняется запрос по адресу, указанному в атрибуте hx-get. Этот атрибут встроен в htmx. Мы обращаемся к серверу, получаем от него фрагмент HTML, который возвращает веб-сервис, и вставляем этот фрагмент в страницу. За то, куда он вставляется, отвечает атрибут hx-target. По умолчанию содержимое ответа заменяет текущий тег, но это можно изменить, указав другой элемент в hx-target. В данном случае при нажатии на кнопку «Нажми меня» запрос идет по адресу /reaction, получает ответ от сервера и вставляет его в блок с идентификатором output. Этот идентификатор задан в hx-target. Это базовый принцип работы htmx.
Главное отличие в том, что htmx возвращает не JSON, а готовый HTML, отрендеренный на сервере.
Веб-разработчики создали htmx для себя, чтобы решить проблемы фронтенда в своем мире. Нам эти проблемы не очень знакомы.
Htmx появился как протест против современного фронтенда, который разросся. Там множество технологий и инструментов, которые меняются каждый месяц, постоянно выходит что-то новое, мода очень скоротечна.
Главное, что htmx позволяет ликвидировать состояние на клиенте – рассинхрон между состоянием компонента на клиенте и его аналогом на сервере. Поскольку клиентского состояния нет, а сервер рисует всю страницу и выполняет все вычисления, современные серверы способны быстро отвечать клиентам. Клиент при этом полностью разгружается. В браузере не происходит никаких преобразований кода. Все, что нужно сделать клиенту, – просто получить ответ и вставить его в нужный фрагмент страницы. Благодаря этому клиент становится сверхтонким: на его стороне не выполняются никакие вычисления. Работать можно хоть с калькулятора.
Мы полностью забываем про JSON и используем серверный язык – любой, какой угодно. Вы абсолютно независимы: можете писать на Python, C#, JavaScript, Элементе, на чем угодно. Главное – чтобы можно было поднять HTTP-сервис и через него отвечать.
Так выглядит JSON, который мы обычно отдаем в стандартном вебе – только данные.
А вот так выглядит ответ от сервера с помощью htmx: мы сразу отдаем с сервера фрагмент HTML и используем атрибуты, через которые задается поведение. С их помощью можно сразу определить логику. Сервер становится всемогущим.
Я делал демонстрацию – пример на 1С:Элемент. Здесь есть две роли.
Первая – человек с улицы, не знакомый с 1С. Он заходит в приложение, оставляет заявки на мастер-классы, добавляет их в корзину, выбирает удобные даты и отправляет. Все это реализовано целиком на htmx – без единой строки JavaScript или какого-либо другого кода, кроме HTML и серверного кода 1С:Элемент.
Вторая роль – back-office. Это человек, который обрабатывает заявки через стандартный интерфейс 1С:Элемент. А витрина, то есть пользовательская часть в этом же приложении, реализована на HTML. Логин – demo, пароль – demo.
После входа все выглядит примерно так. Вверху видно HTTP-сервис ApplicationDataОбработкаЗапроса. Когда выполняется запрос к этому endpoint, происходит определенное действие. В заголовке и теле ответа можно указать дополнительные события. В теле передается HTML, который нужно использовать.
Код пишется просто. В 1С:Элемент это удобно благодаря интерполяции строк. Подсветки HTML в среде разработки нет, но подсветка переменных есть, и работать с этим удобно.
Ограничения htmx и необходимость гибридных решений
Конечно, HTML нельзя использовать везде и в каждом проекте – иначе этой статьи бы не было. HTML здесь серверный, и когда у вас тысяча клиентов, все они обращаются к одному серверу, чтобы он отрендерил им фрагменты страниц, то серверу может стать тяжело. Поэтому htmx подходит для проектов, где нужно немного улучшить интерфейс и где на странице не происходит слишком много событий. При этом одно событие может быть связано с другим.
Если в проекте ведется серьезная работа с медиа, например создается графический редактор или что-то подобное, htmx лучше не использовать. У меня был пример, когда в приложении было много различных клиентских состояний, и невозможно на каждое переключение вкладки каждый раз обращаться к серверу, запрашивать фрагмент и вставлять страницу. Это слишком затратно, и пользователю может быть критично ждать секунду-две, пока придет ответ.
Создание собственной библиотеки для обработки событий в HTML-контейнере
Я решил поискать решение и придумал простейшую доработку. Если у контейнера нет событий, но начиная примерно с 6–7 версии появилась возможность взаимодействовать с JavaScript внутри контейнера, почему бы не написать эти события самостоятельно?
Логика простая. Я договорился сам с собой, в каком виде буду возвращать информацию о событии: какого оно типа, с каким компонентом произошло, что нажали, куда нажали, что переместили, куда переместили, какие параметры были к нему прикреплены.
Через определенные интервалы времени я опрашиваю контейнер и передаю эту информацию с помощью небольшой библиотеки на JavaScript, которую написал один раз и теперь встраиваю во все проекты, где использую эту технологию.
Поскольку одно из преимуществ 1С:Предприятие Элемент – модульная структура, библиотеки можно встраивать без необходимости перекидывать подсистемы, как это приходится делать с БСП в «восьмерке». В результате нам не нужно писать JavaScript каждый раз заново.
Разработчику не нужно писать JavaScript – он сможет поддерживать решение, используя только средства встроенного языка 1С:Элемент.
Выглядит это примерно так. Внутри объекта JavaScript, который лежит в контейнере HTML, есть какой-то ответ. Вы получаете информацию о самом событии, запаковываете это в человекочитаемую структуру на уже встроенном языке, чтобы в дальнейшем с этой структурой на клиенте или на сервере что-то делать.
Для конечного разработчика на встроенном языке 1С:Элемент это выглядит просто: если нажата кнопка с определенным идентификатором – выполняется нужное действие. Цель такого подхода в том, чтобы можно было уйти из проекта, а 1С-разработчики могли без труда продолжать поддержку.
Практическое применение: кейс с корпоративным порталом
У нас есть внутренний заказчик, для которого требования к интерфейсу особенно важны – это департамент, отвечающий за корпоративные мероприятия.
Пример – сайт, целиком написанный на этой библиотеке, которую я назвал Vs Ui. Это приложение полностью реализовано на 1С:Элемент и хостится в облаке. Одна из его ролей предназначена для конечного пользователя: по определенной ссылке открывается интерфейс, а back-office части системы, где можно сэкономить время, использует стандартные формы 1С:Элемент, нативные компоненты и другие встроенные возможности.
Это не отказ от стандартных инструментов, а способ расширить их возможности в облаке. Приложение работает на платформе 1С:Предприятие. Это HTML-контейнер растянут по горизонтали и вертикали, и внутри него реализован весь интерфейс. Сюда я навайбкодил дизайн и небольшой скрипт, который позволяет элементам интерфейса двигаться в зависимости от позиции курсора. Я теперь могу делать все, что угодно из того, что умеют делать вебщики.
Как это выглядит с точки зрения прикладного разработчика: есть контракт, который называется VS-компонент. Этот контракт обязывает вас реализовать метод тела, который отвечает за рендер отдельно взятого компонента, и обязывает реализовать обработчик события, чтобы внутри этого события обрабатывать: нажали туда, перетащили то, создали то. И есть метод, который обязывает задать уникальный идентификатор для того или иного компонента, который реализует этот контракт. Реализацией контракта вы можете делать все, что угодно.
У меня в примере есть структура. Панель навигации – это отдельный компонент в моей библиотеке, фреймворке, где есть баланс, текущий раздел, размер корзины. Это все лежит на клиенте в специальной коллекции и сохраняет свое состояние.
Чтобы отрисовать в контейнере в любой момент времени текущего состояния этот компонент, вы вызываете метод тела у реализации этого контракта. Метод тела смотрит на все переменные, которые лежат в экземпляре этой структуры (у вас может быть что угодно) и перерисовывает его в том виде, в котором вы захотите.
У меня есть еще один пример. В методе тела, о котором я говорил, зашито много логики: наименование, описание, настройки вариаций, кнопка действия. Что это такое?
Это просто поля, принадлежащие этой структуре. Соответственно, вы на встроенном языке, оперируя этими полями на русском языке в 1С:Элемент, управляете фронтендом.
Если придерживаться такой парадигмы, можно спокойно передавать проект на поддержку – специалисты 1С смогут его сопровождать.
Как я уже говорил, у нас есть разные роли: одна на стандартном нативном интерфейсе, другая – на Vs Ui. Но это не значит, что теперь нужно вайбкодить все. Нет смысла вайбкодить всплывающие окна или модальные формы, если они уже есть в 1С:Элемент. Средств встроенного интерфейса 1С:Элемент вполне достаточно, чтобы стилизовать его под интерфейс вашего HTML-контейнера так, чтобы пользователь не заметил разницы.
Пример кода выглядит так. Есть событие при взаимодействии с контейнером. Если нажат компонент с идентификатором кнопка формы, выполняется действие – задается вопрос с помощью стандартной библиотеки 1С:Элемент.
Появляется всплывающее окно, и мы на клиенте, без обращения к серверу, обрабатываем ответ пользователя и выполняем нужные действия в зависимости от выбора.
Далее у меня возникла потребность реализовать drag-and-drop. Вот пример фрагмента, с помощью которого можно это сделать на уровне библиотеки: фиксируется, что и куда перетащили.
На уровне события во встроенном языке задается логика: если элемент перетащен в определенную колонку, то значением этой колонки становится нужный элемент справочника или реквизит.
Таким образом, логика переносится из JavaScript во встроенный язык 1С:Элемент, чтобы код оставался читаемым и поддерживаемым. Уверен, со временем появится и нативный drag-and-drop от вендора, но тогда решение было нужно срочно.
Пример использования: платформа для стажеров и создание эмоционального опыта
У нас есть платформа для обучения, созданная на стандартных компонентах 1С:Элемент. У нее высокая оценка по интерфейсу, аудитория приняла ее очень тепло.
Есть версия этого интерфейса, реализованная на Vs Ui, которую я тоже навайбкодил, оставаясь в экосистеме 1С:Элемент. Это платформа, где пользователи могут загружать задания, скачивать файлы, переписываться с преподавателями. Мы используем ее в основном для стажеров: они приходят на программу стажировки и через этот личный кабинет получают доступ к обучающим материалам.
Интересная деталь – аудитория в основном молодая, зумеры и даже представители поколения альфа. Им нравятся игровые элементы: кейсы, призы, награды. Поэтому за выполнение домашних заданий можно открыть специальную карточку – артефакт с интересными фактами из мира 1С.
Это возвращает нас к началу статьи – к теме пользовательского опыта и впечатлений. Для стажера участие в программе – стресс: неизвестно, дадут ли оффер, возьмут ли на работу. Но даже если нет, взаимодействие с таким интерфейсом оставляет положительные эмоции. Благодаря вниманию к деталям – анимациям, смене фона, даже музыке на фоне – человек чувствует, что о нем позаботились. И в итоге у него остается позитивное отношение к бренду, потому что опыт взаимодействия был комфортным.
Это https://gitflic.ru/company/enterprise_element_community открытый репозиторий от участников сообщества, которые готовы делиться исходным кодом. В том числе, там будет размещена библиотека, о которой шла речь.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.
Вступайте в нашу телеграмм-группу Инфостарт