Практика разработки интерфейса на примере Терминала путевых листов

Эта статья основана на личном опыте, экспериментах и практике разработки интерфейса на примере терминала путевых листов.

Я 1С-ник, а еще немного блогер и аналитик. С 1С я работаю уже около 10 лет, а свой путь в IT начал еще со студенческой скамьи. Сейчас я тружусь в аккредитованной IT-компании Mag Development, которая сосредоточена на проектах для крупного пищевого холдинга «КДВ-Групп». Думаю, многие из вас пробовали продукцию этой компании.
 

Ограничения платформы 1С в дизайне интерфейсов

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

Из-за этого большинство участников разработки дизайн либо откладывают «на потом» и относят к техническому долгу, либо сводят к декоративным мелочам. Основное внимание уделяется коду – его качеству, производительности. А производительность интерфейса уходит на второй план.

Но даже без профессиональных дизайнеров интерфейсы создаем мы все. Платформа этого требует: мы одновременно и backend-, и frontend-разработчики. Кто-то в меньшей, кто-то в большей степени, но так или иначе каждый 1С-ник разрабатывает интерфейсы.

Вот и я – такой же «не дизайнер», как и все, – хочу поделиться своим опытом.
 

Анализ внешних подходов к дизайну в 1С
 

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

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

Я восхищаюсь такими интерфейсами и дизайном, но это уже не про 1С и нам это, как правило, не близко.

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

Но иногда разработчики перегибают: используют чрезмерно яркие, кислотные цвета. Особенно это было популярно во времена 7.7. Я уже пришел в 1С на версии 8.3, поэтому видел это скорее как рудименты. Часто попадались интерфейсы с явной безвкусицей или халатным отношением к графике. Порой встречались настоящие «сумасбродства», и в итоге страдало главное – восприятие интерфейса и удобство работы пользователя.
 

Чек-лист доработки типовых интерфейсов
 

И здесь у вас закономерно возникнет вопрос: «Ну ладно, расскажи уже, как правильно». Первое, с чего я хочу начать, – это чек-лист доработки типовых коробок.

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

Про сам стандарт можно почитать по ссылке https://its.1c.ru/db/v8std. Он не такой большой, как может показаться.

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

Следующие два пункта связаны с тем, о чем мы говорили выше:

• используйте спокойные цвета;

• применяйте готовые коллекции иконок от дизайнеров, которые специализируются на иконографии.
   

Отдельно хочу остановиться на стандарте, потому что там есть любопытные моменты. Например, представлены сразу две компоновки формы. Казалось бы, зачем? Напишите одну. Но разработчики оставили оба варианта, и они встречаются в популярных решениях. Где-то используются вкладки, а где-то все реквизиты выводятся сразу.

Универсального рецепта «какой вариант лучше» у меня нет. Я лишь хочу подчеркнуть, что даже стандарт несовершенен.
 

Теория разработки интерфейсов: лестница проектирования
 

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

Остановлюсь подробнее на ключевых ступенях этой лестницы.
 

Персонаж – это самый важный анализ при создании нетиповых интерфейсов. Вы должны четко понимать, для кого работаете:

• ваш пользователь знаком с 1С или нет?

• бухгалтер он или другой специалист?

• какие реквизиты должны быть на форме?

• какой пользовательский сценарий будет для него удобнее?

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

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

• самые простые, низкодетализированные,

• среднедетализированные, где уже можно оценить структуру;

• высокодетализированные, почти готовые решения, в которых интерфейс можно «потрогать» – покликать, подвигать элементы, проверить сценарии.

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

Инструменты для прототипирования интерфейсов
 

Какие инструменты можно использовать для прототипирования? Самый простой и популярный – это обычная бумага. Когда я работал в офисе, бумаги в бухгалтерии было завались – особенно черновиков. Это было невероятно удобно: взяли лист, сели с заказчиком за стол, набросали форму, обсудили, согласовали – и готово. Можно переходить к разработке интерфейса, который будет одинаково понятен и вам, и заказчику. Польза очевидна и достигается быстро.
 

С переходом на удаленку бумага отошла на второй план, и на смену пришел другой удобный инструмент – Excel. На нем держится мировая экономика, но и прототипы в нем вполне реально делать. Принцип такой же: созвон в Telegram, шарим экран, набрасываем форму. Если устраивает – согласовываем и идем дальше. Быстро, дешево и экологично – ни одно дерево не страдает.
 

Есть и специализированные инструменты для прототипирования – как известные, так и нишевые. Например, 1Cmaker.com, в котором есть готовые элементы, похожие на наши стандартные формы, и 1С:Эскиз. В своем блоге я делал сравнительный разбор этих решений: у каждого есть плюсы и минусы, свои нюансы.
 

Ну и, конечно, когда речь заходит о прототипировании, нельзя не вспомнить про Figma. Это, пожалуй, самый мощный инструмент, позволяющий создавать максимально презентабельные прототипы. Здесь прототип – это уже почти готовое решение: можно кликать, переходить по сценариям, открывать формы. Смотрится очень круто, но требует времени на освоение. Это уже не та «бумажка», что была под рукой, а полноценный продукт, который можно продавать заказчику за серьезные деньги.

Кстати, у «Инфостарта» есть курс по работе с Figma – при желании его можно пройти.
 

Практический кейс: терминал путевых листов
 

Переходим ко второй части статьи – практике, где я расскажу о кейсе терминала путевых листов. Я работал в одной компании, где, как это часто бывает, «оптимизаторы» оптимизировали персонал. В итоге получилась такая ситуация: водители и диспетчер почти никогда не пересекались.

Водители приходили рано утром, брали заранее подготовленные путевые листы и уезжали. Диспетчер же начинал работу позже и заканчивал раньше, чем возвращались водители. В результате весь учет ГСМ и своевременная сдача путевых листов превратились в хаос. Проблему нужно было решать.

Возвращать людей в штат, конечно, никто не собирался – «делайте автоматизацией». Мы стали изучать рынок и увидели, что терминалы путевых листов уже существуют. Но в 2019 году их стоимость равнялась примерно четырем зарплатам регионального программиста (как раз столько я тогда получал). Причем это был просто терминал без интеграции – ее еще нужно было отдельно разрабатывать под «Управление автотранспортом».

Так и родилась идея: «А почему бы не попробовать сделать все это на 1С?» Бюджет – те самые четыре зарплаты. Сроки – четыре месяца. Проект стартовал.
 

Концепция была такая: сенсорный монитор (как на картинке), сканер, принтер и тумба, в которой все это собрано. Идея есть, двигаемся дальше.

Следующий шаг – персонаж. Для кого мы это делаем? Очевидно, для водителей. Их уровень владения компьютером минимален: они не знают, что такое 1С, и точно не будут работать с мышкой и клавиатурой, чтобы проводить документы или заполнять путевые листы. Это категорически не подходило.

Раз мы решили делать сенсорный терминал, интерфейс должен быть максимально простым. Опирались на привычный опыт: в 2019 году большинство уже умело пользоваться банкоматами и терминалами Сбербанка. Значит, и здесь должно быть так же просто. Мы проектировали интерфейс под конкретную аудиторию: под «мужиков с большими пальцами» и под принцип «чтобы даже моя бабушка могла разобраться».
 

Прототипирование и разработка интерфейса терминала
 

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

Художественные навыки тут не нужны. Важно лишь согласовать с заказчиком общий вид и прийти к единому пониманию, что именно должно быть на экране.
 

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

В конфигураторе начинается программирование. Для интерфейса нужен отдельный движок – метод, который будет управлять всем этим хозяйством. Я разработал метод, которому передавались заголовок, номер слайда и набор кнопок. Под капотом получился своего рода back-end – «движок управления интерфейсом», который переключал элементы в зависимости от назначения.

Но речь у нас не про внутреннюю механику, а про front-end. И вот здесь начались неожиданные сложности.
 

Первое, с чем мы столкнулись – водители. У них большие пальцы, и стандартная всплывающая клавиатура для ввода значений оказалась совершенно неудобной. Попробуйте сами попасть по маленьким кнопкам «калькулятора» 1С на сенсорном экране – то еще испытание.

Системная клавиатура Windows тоже не спасала: иногда тормозила, а иногда была перегружена лишними кнопками.

Решение оказалось простым – мы сделали собственный калькулятор ввода, специально для указания количества топлива.

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

Кстати, это второе решение я опубликовал на Инфостарте в свободном доступе – его можно посмотреть и попробовать //infostart.ru/1c/reports/888041/.
 

Использование поля HTML и режима «Киоск»
 

Дальше у нас встал вопрос правильного применения поля HTML. Суть в том, что поле HTML, когда мы говорим про 1С, должно выполнять одну функцию – по тому же принципу, что и хороший чистый код: одна ответственность, одна задача. Раньше часто просто вставляли поле HTML на форму и реализовывали в нем весь интерфейс целиком. Да, выглядит круто – если есть деньги, то почему бы и нет.
 

Правильное использование поля HTML – это вывод статической или полустатической информации. Верстка такой страницы обычно простая и быстрая – пару минут работы.

По части разработки в терминале мы задействовали важный прием – режимы вывода платформы. Один из них называется «Киоск». В этом режиме экран блокируется: показывается одна форма, скрывается панель задач Windows и все служебные меню 1С – на экране остается только нужная пользователю обработка. Это удобно для сенсорных терминалов.
 

Код реализации относительно простой; у платформы есть и другие режимы, о которых можно почитать в блоге фирмы 1С https://wonderland.v8.1c.ru/blog/novye-rezhimy-osnovnogo-okna/
 

Оптимизация и финальные доработки терминала

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

Во время тестирования обнаружились интересные фичи.
 

Первая фича – терминал мог зависать, и было непонятно, что происходит. Напомним, пользователь у нас новичок. Чтобы он понимал, что система работает, мы добавили индикатор времени: если секунды шли – терминал в порядке, если нет – значит, нужно звонить в техподдержку. Пользователь также мог поиграть с виджетом-индикатором, который показывал работу терминала.
 

Вторая фича была связана со сканером: при сканировании путевых листов он периодически непредсказуемо отключался. Для пользователя сделали простой способ диагностики: на экране отображался статус подключения сканера. Если возникала ошибка, можно было просто нажать на гиперссылку – и сканер пытался переподключиться автоматически. Если не удалось – звоните в техподдержку. Нагрузка колоссально снизилась благодаря этому решению.
 

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

Итоги и дополнительные находки в разработке
 

В результате этапа начальной разработки и процесса оптимизации интерфейс немного изменился. Появился даже третий сценарий – но это уже специфика конкретного предприятия.

Все было готово к релизу: терминал ушел в продакшен и успешно запущен.
 

Хочу затронуть еще один момент, который также имеет отношение к терминалам и сенсорным интерфейсам. Одна из ключевых проблем при разработке терминала была связана с элементами формы: при увеличении реквизита с признаком флажка сам флажок не масштабировался – увеличивался только шрифт.

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

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

Альтернативные решения и вдохновляющие примеры
 

Хочу немного заострить внимание на альтернативе. На момент разработки нашего терминала путевых листов готового решения от «Раруса» не было, но позже оно появилось. У них тоже есть свой терминал путевых листов, интерфейс выглядит примерно так, как показано на картинке. Это универсальное решение, немного перегруженное, но я бы с удовольствием использовал его как backend, а фронт все равно написал бы свой – максимально упрощенный и заточенный под конкретный бизнес. Именно это и есть проектирование дизайна интерфейсов: мы можем упростить работу пользователя и сделать ее быстрее и удобнее.
 

На десерт хочу показать действительно интересный интерфейс. Он разработан моим знакомым. На изображении вы видите журнал внутренних документов. Удивительная форма, категорически не похожая на стандартную 1С. Сначала может показаться: зачем так сделано?

Немного контекста: пользователи, работающие с этим интерфейсом, вообще не знакомы с 1С и бухгалтерией. Это сотрудники вейп-магазина, возраст которых около 20 лет. Для них стандартная 1С кажется слишком сложной. А этот интерфейс воспринимается естественно и понятно – ничего лишнего, все на своих местах.

Это пример, когда разработчик вышел за рамки моего «канонического листа» – чек-листа доработки типовых форм. Он переработал все внешние формы интерфейсов, сделав работу максимально простой и понятной. Решение очень удобное: весь журнал просматривается буквально за несколько кликов – 2–3 кнопки, и вся информация доступна.
 

Завершение: текущие достижения и гордость команды
 

И хочу поделиться своей гордостью, текущим достижением команды. Мы переработали интерфейс типового АРМа по формированию заказов по потребности в УТ-11 и сделали режим одного окна. На первый взгляд это может показаться странным, но на самом деле эффект огромный.

Благодаря этому инструменту пользователь больше не делает постоянные пять шагов: перезапуск, переоткрытие – все это теперь не нужно. Окно всегда открыто, и пользователь работает в нем непрерывно, в режиме одного окна обслуживая порядка 20 фабрик пищевого производства. Аналогов такого функционала практически нет – это наше ноу-хау, очень мощное и удобное решение.

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

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.