Методология разработки в Mobile SMARTS такова, что функционал приложения изначально неотделим от пользовательского интерфейса. Можно считать это отходом от идеалов разделения представления от дизайна, но в этом есть определенный смысл.
Имея определенный опыт в разработке заказных приложений для терминалов сбора данных (ТСД), разработчики «Клеверенс» наблюдали интересную закономерность, когда из ТЗ в ТЗ (хотя они и были составлены совершенно разными специалистами) кочуют примерно одни и те же формочки, отражающие примерно одинаковую логику работы персонала с мобильным устройством. Почти всегда есть окошко логина по паролю или штрихкоду. Просмотр строк задания с колонками требуемого и выполненного количества (план/ факт). Ввод каких-то дат. Сканирование адреса ячейки/ палеты/ коробки. «Esc для отмены, F4 - подтвердить» и т.д.
Еще одним характерным моментом было отличие между формочками «новичков», и теми интерфейсами, которые рисуют «ветераны» автоматизации.
Формочки за авторством «новичков» - перегруженные информацией формы, много мелких полей ввода, на каждом экране какие-то кнопочки - для работы требуют стилуса, хорошего зрения и инженерного образования.
Формочки за авторством «ветеранов» - это минимум текста, очень крупно, никаких кнопок. В первом случае: «для выбора товара отсканируйте ШК с упаковки или нажмите F1 для выбора из списка», во втором: «СКАНИРУЙ ТОВАР».
При этом не нужно забывать, что хотя почти каждое ТЗ для ТСД начинается со скриншотов, экраны устройства - это далеко не сама программа. За любой формочкой кроется большой пласт бизнес-логики, обменов данными и т.п. вещей.
В итоге разработчиками Mobile SMARTS было принято соломоново решение: создать систему, которая бы оперировала предопределенным набором наиболее полезных экранных форм с уже готовым отлаженным кодом обработки их поведения.
Каждая такая форма должна конфигурироваться только в тех пределах, в которых это не «сломает» работу приложения. При этом возможности по визуальному оформлению форм никак не ограничиваются, т.к. в платформу внедрен свой рендер HTML + CSS.
Наконец, конкретный набор форм и возможностей по их конфигурированию должен будет расширяться до тех пор, пока большинство ТЗ не смогут быть реализованы в таком виде без ущерба для итогового функционала приложения. Теоретически это путь без конца. На практике он заканчивается с набором определенной критической массы пользователей и приложений.
