Множество требований, предъявляемых к UIMS, и критериев их оценки строится, исходя из основной эталонной модели UIMS (см. рис.1). Эта модель представляет систему в виде двух компонент: инструментария, используемого на стадии разработки диалога и части, относящейся ко времени исполнения (run-time portion). UIMS обычно предоставляет способ управлять последовательностью действий конечного пользователя. Структура диалога задаётся вне прикладной программы. Это даёт возможность разработчику диалога экспериментировать с диалоговой последовательностью без необходимости каждый раз заново компилировать всю прикладную программу.
В составе UIMS должен присутствовать инструментарий WYSIWYG -- для облегчения конструирования макетов экранов, структур меню и диалоговых последовательностей. Должно быть возможно использовать наработки (например, библиотеки интерфейсов, диалоговых структур), в последующих разработках. UIMS должна использовать для представления информации пользователю существующие графические библиотеки и администраторы оконных систем. Определение диалога, будучи заданным, преобразуется в некое формальное описание диалога, которое может представлять собой как файл данных, так и код (исполнимый: машинный, либо на языке виртуальной машины). Впоследствии этот файл, будучи соответствующим образом скомпонованный с прикладным кодом, должен будет породить работающую конечную систему.
Именно здесь принимается решение, как будет выглядеть конечный продукт. Это не строгое определение, но указание направления разработок. Приложение не должно накладывать жёстких ограничений ни на внешний вид интерфейса, ни на его идеологию; в интерфейсе продукта должно быть возможным реализовать любые идеи. Отсюда естественным образом вытекает требование: UIMS должна предоставлять возможность экспериментирования с интерфейсом на ранних этапах разработки.
Подразумевается возможность автоматического создания дизайна пользовательского интерфейса исходя из его описания. Первый черновой вариант такого дизайна должен быть приемлем в качестве входных данных для следующих уровней доводки UIMS. Путь от спецификации через прототип к конечному варианту должен быть хорошо определён и автоматизирован. Возможно использование автоматического инструмента дизайна для изготовления различных вариантов и форм интерфейса из одного и того же описания -- управление вариациями может осуществляться либо через непосредственное манипулирование, либо через системы меню, либо на командной основе. Выбор варианта из полученного множества -- за дизайнером.
Семантика приложения может быть выражена в терминах поведения объектов и действий пользовательского интерфейса. Например, красный цвет ассоциируется с риском, а зелёный -- с безопасностью. Такие ассоциативные связи могут быть выгодно использованы в интерфейсе. UIMS должна предоставлять возможность определять и по мере необходимости позже изменять подобные соотношения.
Это подмножество критериев охватывает те из них, которые могут быть полезными для разработки пользовательского интерфейса.
Желательно наличие инструментов, которые могли бы помочь дизайнеру интерфейса вникнуть в суть поставленной задачи, которую конечный продукт и призван (помогать) решать. Эти инструменты могли бы помочь выработать модели данных и поведения пользователя при работе с ними, оказать содействие при сборе информации и управлении данными. Инструментарий должен также предоставлять средства для быстрого создания прототипа, который можно было бы многократно использовать в конечной системе -- для экономии времени и сил. Знания полученные на этапе выяснения требований должны использоваться для создания формального описания интерфейса, которое и должно отражать выдвигаемые к интерфейсу требования. Если требования изменятся, то частично изменится и спецификация, и поэтому возникает необходимость в средствах, которые позволили бы проследить путь от требований к спецификации, т.е. выяснить, как выходная спецификация зависит от каких-либо входных данных/требований. Эти же средства можно использовать для проверки спецификации на предмет соответствия выдвигаемым требованиям.
UIMS должна поддерживать широкий диапазон приложений и пользователей. UIMS должна также поддерживать широкий диапазон стилей взаимодействия: как низкоуровневые, типа командной строки, так и высокого уровня, как, например, графическое манипулирование с лексической или семантической обратной связью, непосредственное манипулирование графическими объектами, а в последующем -- и виртуальную реальность.
Далее мы будем использовать термин ``графический ввод'' для обозначения простого распознавания символов; ``стандартное меню'' -- для меню, которое видно на экране всегда.
Предоставляет ли UIMS возможность настройки интерфейса разработчиком или конечным пользователем? Управление настройкой может быть лексического уровня, например, пользователь определяет, где и как расположены меню и другие интерактивные графические объекты на экране, использовать ли для привлечения внимания звуковой или световой сигнал. Управление может быть частью синтаксиса взаимодействия, т.е. структура диалога может изменяться пользователем, с тем чтобы изменять существующие команды, вводить новые, расширять функциональные возможности приложения и, соответственно, пользовательский интерфейс.
Большинство компаний стремится выполнять все свои приложения в своём собственном ``фирменном'' стиле, который распространяется и на интерфейсы их продуктов. UIMS должна обладать достаточной гибкостью, чтобы быть способной воспринять внешний стиль. Если это не так, то компании, использующие одну и ту жу UIMS, скорее всего, будут вынуждены создавать приложения в стиле, навязанном UIMS, а не в своём собственном -- будет трудно придать индивидуальность своему творению, если UIMS не предоставляет возможности подстройки под нужды конкретного класса продуктов. Дизайнер должен иметь возможность задать индивидуальный стиль взаимодействия и представления. Причём, должно быть возможно задать любой стиль только раз и затем использовать его в любых последующих разработках, их пользовательских интерфейсах.
UIMS должна отделять прикладную часть программы от части пользовательского интерфейса: каждый раздел должен писаться отдельно. Управление системой может осуществляться как из интерфейсной части (посредством UIMS), так и из прикладной чсати.
UIMS обычно состоит из двух основных модулей: препроцессора разработки и реализации пользовательского интерфейса и рабочей (run-time) среды, в которой и работает интерфейс пользователя.
UIMS должна отделять прикладную часть программы от интерфейсной. Должно быть возможно работать над этими частями раздельно.
Управление системой может осуществлять либо UIMS -- посредством управляющих действий со стороны интерфейсной части, либо прикладная часть. Либо приложение запрашивает пользователя о вводе, либо же инициатива во взаимодействии принадлежит пользователю. Если управление принадлежит UIMS, то обычно она вызывает прикладные модули по мере необходимости в ответ на действия конечного пользователя. Такое управление можно назвать ``внешним''. Если управление всегда осуществляется из прикладной части, то такое управление можно назвать ``внутренним''. Третий вид управления -- пользователь полностью управляет системой. Настоящая UIMS предоставляет средства для осуществления внешнего управления, в то время как инструментарий предоставялет средства только для создания системы с внутренним управлением.
UIMS должна допускать возможность ввода множеством разных способов. Пользователь может использовать только одно устройство ввода, UIMS же сама должна решать -- которое именно (мышь или клавиатура). Пользователь может работать и со множеством устройств ввода, UIMS должна учитывать возможность такой ситуации и правильно её обрабатывать. Используемый метод зависит от того, как UIMS логически представляет ввод, а не от того, как он реализован.
Этот раздел охватывает инструменты разработки интерфейса (IDT -- Interface Design Tool). Эти инструменты дают возможность интерактивного построения пользовательсокго интерфейса. Возможен и, вероятно, более предпочтителен вариант, в котором дизайнеру вообще не надо писать программный код самому -- необходимый для компоновки в окончательную систему код будет порождён автоматически. В этом случае дизайнер может изменять интерфейс, не меняя никакого кода, и приложение можно сразу же собирать с этим новым интерфейсом.
Компоненты, допускающие многократное использование, повышают производительность труда как программиста, так и дизайнера; они предоставляют возможность стандартизации и гарантии полной проверки всех составных частей интерфейса. Поэтому желательно, чтобы UIMS имела средства для универсализации программных компонент -- для облегчения их повторного использования. Такие средства могут представлять собой отладочные, проверочные и аналитические инструментарии. В составе UIMS должна присутствовать компонента, реализующая систему ведения соответствующим банком модулей, т.е. архивирования, индексирования, хранения и выборки универсальных модулей и их спецификаций. Должна иметься возможность задания семантики программных модулей -- для осуществления поиска модуля с соответствующими функциями.
Желательно, чтобы UIMS предоставляла возможность оттранслировать спецификацию диалога в программу на стандартном языке выского уровня.
Использование таких возможностей, как интерактивный дизайн диалога и пробный/отладочный прогон, избавляют разработчика диалогов от необходимости формального программирования. В этом случае единственно необходимым является только программирование прикладной части системы. Ясен пень, если эта прикладная часть создаётся отдельно и другим человеком, то дизайнеру интерфейса вообще не надо писать никаких программ. В идеале интерфейс должен полностью создаваться средствами UIMS.
Система может быть формально описана в терминах языка типа BNF или же конечных автоматов. Последняя модель, вероятно, более проста для понимания человека, не искушённого в программировании.
UIMS должна автоматически создавать программные ``заглушки'' для отсутствующих процедур обработки событий. Система при обращении к такой несуществующей процедуре может, например, просто выводить на экран сообщение, что вызвана конкретная процедура.
Макросы суть сокращённые записи кусков программного кода. Макроопределения раскрываются в полную свою форму либо препроцессором, либо непосредственно во время исполнения. Макрос определяется в процедуре и хранится в библиотеке. Библиотеки макроопределений позволяют использовать их как строительные блоки для других приложений. Макросы могут использоваться в рекурсивной форме.
Как много деталей должен задавать в описании дизайнер? Можно ли заставить UIMS сконструировать интерфейс, предоставив ей только список операций и ничего более? Уровень детализации должен быть регулируемым, чтобы можно было, задав изначально общее описание и получив продукт в некоем виде, далее его довести до желаемого состояния, используя более высокую степень детализации. Система должна допускать любой уровень детализации и предоставлять дизайнеру полную свободу выбора уровня, на котором он будет вести работу. На всех уровнях детализации должны быть заданы разумные умолчания, которые должно быть возможным изменять по мере необходимости.
Этот раздел охватывает многообразие переменных и выражений доступных разработчику.
Прикладной программист или дизайнер диалога должны иметь возможность пользоваться средствами язка программирования, на котором пишется система (например, ``C''), для создания различных структур данных, например, записей событий.
Проверка типа и допустимости значений облегчает обработку данных вводимых пользователем. Эту проверку может осуществлять либо UIMS, либо программный код дизайнера интерфейса. При обнаружении ошибки должно выводится сообщение о таковой и/или подсказка о необходимых свойствах ожидаемых данных.
Выражения могут быть как арифметическими, так и частью диалога. Вычисляются ли значения выражений во время работы UIMS или конечной системы? Производятся ли вычисления прикладной частью или внешними программами, написанными на другом языке? Следует учитывать возможность использования графических объектов в качестве именованных переменных в вычислимых выражениях.
Если значение параметра пользователем не задано, система должна быть способна использовать значение по умолчанию, определённое разработчиком интерфейса.
Этот раздел охватывает взаимодействие аппаратного и программного обеспечения системы на низком уровне. Затрагиваются вопросы программной эмуляции аппаратуры и использования мультимедиа.
Если UIMS переносится на некоторую аппаратную платформу, то перенос и пользовательского интерфейса, и конечного приложения должен осуществляться автоматически.
Иногда возникает необходимость управлять устройствами на низком уровне из контекста языков высокого уровня. В ОС UNIX для осуществления такого управления следует просто создать свой собственный драйвер и виртуальное устройство в ядре системы, но это очень непросто осуществить в UIMS. Низкоуровневое управление может использоваться также и для того, чтобы добиться качества, соответствующего используемой методике взаимодействия. Мощность и гибкость UIMS определяется возможностью задания полного спектра интерактивных техник, но качество реализации зависит не в последнюю очередь от возможности использования в диалоговой системе низкоуровневого управления графическими устройствами ввода-вывода. Поддержка UIMS такой деятельности может оказаться весьма полезной. Но необходимость в задании управления на таком уровне должна отсутствовать -- дизайнер не должен об этом думать, если он того не хочет.
UIMS сама должна управлять конкурирующими потоками ввода-вывода различных устройств, с тем чтобы избавить от этой сложной задачи и дизайнера интерфейса, и прикладного программиста. Большинство языков программирования последовательны по природе, поэтому именно UIMS должна управлять одновременным обменом данными с разными устройствами. Здесь же следует рассмотреть возможность взаимодействия пользователя с системой во время производства той вычислений. Пользователь всегда должен иметь возможность прервать вычисления и снова начать взаимодействовать с системой. Блокирование пользователя недопустимо.
Каждый квант диалога, связаный с низкоуровневым вводом, должен предоставлять возможность отменить последний ввод -- сделать шаг назад. В диалоге на более высоком уровне должно быть возможно ``удалить последний параметр'', не вызывая этим никаких ошибок.
UIMS должна предоставлять возможность использовать широкий спектр устройств ввода-вывода, включая средства мультимедиа и виртуальной реальности, а также добавлять в систему новые средства ввода-вывода. Интересно в этой связи было бы задать такой вопрос: ``Насколько сложно добавить в систему управление голосом?''.
Допускает ли UIMS неограниченную свободу движения по диалогу? Диалог может быть ``плоским'' -- так что большинство команд доступны во входной точке диалога, причём, движение по диалогу, начатое подачей команды, должно быть завершено прежде, чем пользователь вернётся ко входной точке. Диалог также может быть:
UIMS может и не работать в среде многооконной системы, но вместо этого она может сама ведать устройствами ввода-вывода. В этом случае возниакет вопрос, сможет ли UIMS обеспечить одновременную работу множества приложений? Даёт ли UIMS возможность использования в приложении многих окон? И если даёт, то допускает ли она одновременный ввод и вывод во всех окнах? (вообще говоря, UIMS может предоставлять только возможность ввода в одном окне и вывода -- в другом.) Если UIMS предоставляет приложению множество окон, то может ли приложение каким-либо образом получить информацию, в какое именно окно был произведён вывод.
Система X Window (или просто X), разработанная в MIT, заслужила неимоверно широкую популярность, особенно в сообществе UNIX. В X базовая оконная система предоставляет высокопроизводительную графику в иерархически организованное множество окон изменяемых размеров (см. рисунок). Вместо конкретного пользовательского интерфейса X предоставляет набор примитивов, поддерживающих несколько стилей и придерживающихся некоторого множества различных идеологий. В отличие от большинства оконных систем базовая ситема в X определяется протоколом клиент-сервер: асинхронная потоковая (stream-based) межпроцессная связь замещает традиционный интерфейс, построенный на подпрограммных и системных (``ядерных'') вызовах, предоставляя возможности использования распределённой графики (см. рисунок).
Использование X Windows в UIMS резко повышает её апаратную и программную переносимость.
Эта область связана возможностями UIMS по работе с графикой, использования, помимо собственного, различных графических пакетов и стандартов. Обладает ли UIMS возможностью настройки на работу с любыми графическими стандартами? Это может быть очень важно, если какое-либо традиционное приложение уже использует некоторый графический стандарт, такой, например, как GKS, и/или требуется усовершенствовать систему и добавить в неё работу с новыми стандартами. Перевод существующего приложения на новый стандарт или подстройка его под другой графический пакет может отнять много времени.
Предоставляет ли UIMS возможность одновременной работы многих пользователей в распределённой вычислительной среде? Предоставляет ли она средства для координации их работы?
Здесь пойдёт речь о возможностях взаимодействия UIMS с другими объектами в вычислительной системе (процессами, операционной системой, etc.).
Предоставляет ли UIMS возможность лёгкого доступа к средствам операционной среды, в которой происходит работа? Вообще говоря, не следует поощрять доступ к операционной системе -- использование системных особенностей может ухудшить переносимость конечного продукта, и UIMS должна ограждать и оберегать дизайнера от общения с системой на низком уровне. Однако, такая возможность всё же должна присутствовать, по крайней мере, это должна использовать сама UIMS, поскольку доступ к средствам операционной системы даст возможность, например, использовать межпроцессный обмен данными и ускорить работу с графикой. Должна существовать возможность увязывать вывод сообщений с определёнными аппаратными событиями, например, с выводом графического документа на печать.
Степень удобства работы с системой очень сильно зависит от количества и качества оказываемой системой помощи. Поэтому при оценке UIMS следует принимать во внимание и то, насколько трудоёмким для разработчика является создание различных уровней систем информационного вспоможения: обычная система подсказок, встроенная система обучения, система обеспечения хорошего стиля разработок.
Весьма полезной для UIMS представляется возможность проследить процесс создания продукта в обратном направлении, получить из конечного продукта его формальное описание в терминах входного языка. Это некая разновидность декомпиляции.
Производительность системы -- важный фактор, которым нельзя пренебрегать. Система может быть лёгкой в использовании, но если она будет слишком медленной, всё её удобство сойдёт на нет.
UIMS должна предоставлять возможность вести протокол взаимодействия пользователя с системой, с учётом всех происходящих в системе событий, проверкой корректности и регистрацией ошибок ввода, пауз, запросов помощи и т.п. Этот протокол должно быть возможно использовать для ввода в UIMS вместо реального ввода с устройств, с тем чтобы можно было воспроизвести сеанс работы, проанализировать его и полученные в его ходе данные, выявить в системе ошибки, слабые места и т.п. Всё это призвано помочь дизайнеру улучшить интерфейс.
UIMS должна предоставлять средства для проверки и оценки качества на всех стадиях разработки. Желательно наличие инструментов автоматической оценки качества интерфейса по различным критериям, таким как планировка экрана, последовательность, стилистичность, модель пользователя и использование устройств ввода. Такой анализ может выявить потенциальные проблемы ещё на стадии разработки, что повысит качество конечного продукта. Если компания имеет свой стиль, либо просто предписывает при разработке интерфейсов руководствоваться какими-либо принципами, то такие инструменты предоставляют возможность проверки разработки на соответствие этим требованиям.