Войти в кабинет Ваша корзина пуста

Построение интерфейса


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

Имея определенный опыт в разработке заказных приложений для терминалов сбора данных (ТСД), разработчики Клеверенс наблюдали интересную закономерность, когда из ТЗ в ТЗ (хотя они и были составлены совершенно разными специалистами) кочуют примерно одни и те же формочки, отражающие примерно одинаковую логику работы персонала с мобильным устройством.  Почти всегда есть окошко логина по паролю или штрихкоду.  Просмотр строк задания с колонками требуемого и выполненного количества (план/факт).  Ввод каких-то дат.  Сканирование адреса ячейки/паллеты/коробки.  «Esc для отмены, F4 - подтвердить» и т.д.

Еще одним характерным моментом было отличие между формочками "новичков" в работе с ТСД и теми интерфейсами, которые рисуют "ветераны" автоматизации.  В первом случае - перегруженные информацией формы, много мелких полей ввода, на каждом экране какие-то кнопочки - для работы требуют стилуса, хорошего зрения и инженерного образования.  Во втором случае - минимум текста, очень крупно, никаких кнопок.  В первом случае: "для выбора товара отсканируйте ШК с упаковки или нажмите F1 для выбора из списка", во втором: "СКАНИРУЙ ТОВАР".

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

В итоге разработчиками Mobile SMARTS было принято соломоново решение: создать систему, которая бы оперировала предопределенным набором наиболее полезных экранных форм с уже готовым отлаженным кодом обработки их поведения.  Каждая такая форма должна конфигурироваться только в тех пределах, в которых это не "сломает" работу приложения.  Наконец, конкретный набор форм и возможностей по их конфигурованию должны будут расширяться до тех пор, пока большинство ТЗ не смогут быть реализованы в таком виде без ущерба для итогового функционала приложения.  Теоретически это путь без конца.  На практике он заканчивается с набором определенной критической массы пользователей и приложений.











Не нашли что искали?

Задать вопрос в техническую поддержку