Стратегию разработки пользовательских интерфейсов в рамках архитектуры Luther можно изобразить следующим образом. В первую очередь, специалисты в предметной области, специалисты по когнитивной психологии и дизайнеры ведут переговоры с клиентом с целью выявить задачи и роли разных рабочих, условия их труда, а также необходимые характеристики интерфейсов для предполагаемых устройств доступа. Далее, исходя из установленных ограничений, они пытаются воссоздать пользовательский опыт, выражая его в виде последовательности кадров, снимков экрана или макета. Все это делается для того, чтобы в процессе проектирования пользовательский опыт моделировался с должным качеством и точностью. Это очень важная задача, поскольку приложение призвано дополнять традиционные технологические операции и быть естественным расширением рабочей среды. Следовательно, воссоздание среды пользователей делегируется тем, кто знает ее лучше других: специалистам в предметной области, которые прекрасно представляют себе задачи и условия труда; специалистам по когнитивной психологии, разбирающимся в том, как люди думают, анализируют и осмысливают информацию; дизайнерам, умеющим представлять информацию в доступном и привлекательном виде.
На следующем этапе артефакты процесса проектирования — последовательность кадров, снимки экрана и макет — оперативно переносятся на работающие пользовательские интерфейсы реальных устройств. В этом контексте от архитектуры требуется обеспечение интеграции различных вариантов пользовательского опыта. Интеграция должна быть быстрой, ориентированной на максимизацию повторного использования универсальных программных элементов и при всем этом способствовать сохранению целостности и точности отражения пользовательского опыта.
Задача переноса пользовательского опыта на реальный пользовательский интерфейс осложняется рядом факторов. Во-первых, необходима поддержка многочисленных клиентских устройств. Среди них — самые разнообразные мобильные устройства с разными размерами экрана, операционными системами и устройствами ввода. Пользовательский интерфейс, который оптимально подходит для употребления на настольном компьютере, значительно ограничивается в возможностях при уменьшении экрана, сокращении ресурсов памяти и сужении функциональности — все эти явления наблюдаются на мобильных устройствах. В частности, некоторые подобного рода устройства не предусматривают поддержки клавиатуры и мыши; соответственно, пользовательские интерфейсы, которые требуют наличия этих средств ввода, становятся совершенно бесполезными. Второй фактор влияния — это технологические ограничения. К примеру, некоторые типы взаимодействия пользователя с системой и отображения информации довольно громоздки и потому при передаче по протоколу HTTP серьезно снижают производительность.
В конце концов, для каждого конкретного приложения могут существовать разные клиентские устройства и пользовательские интерфейсы. Таким образом, от программной архитектуры требуется значительная гибкость — иначе она просто не сможет справиться с многочисленными разнородными клиентами. На рис. 17.4 и 17.5 изображены два типа реализации пользовательского интерфейса, предусмотренные архитектурой Luther, а именно: клиент на основе браузера (рис. 17.4) и специализированный веб-клиент (рис. 17.5). На рис. 17.6 уточняется представление, приведенное на рис. 17.3; там же изображается структура каждого из упомянутых типов.
