Если интерфейс программы не был разработан в расчете на возможное включение режима Large Fonts, все элементы управления "поплывут". Хорошо ещё, если ни один элемент не исчезнет, перекрытый другим.
-
Скорость работы самой системы. Слишком часто, к сожалению, разработчики рассматривают скорость работы системы как фактор, легко терпящий компромиссы. Безусловно, во многих случаях скорость работы может быть принесена в жертву ради другой характеристики системы, но в некоторых ситуациях скорость работы является наиболее важным фактором. Например, если пользователи ожидают высокую скорость работы (к счастью, они ожидают её нечасто), медленно работающая система станет источником значительного субъективного неудовлетворения. Другой пример: во многих системах автоматизации есть операции, выполняемые пользователем во время разговора по телефону (таковы многие операции у брокеров, операторов складов и др.). Если такая операция будет занимать долгое время, проблем разработчику не избежать.
Как и в случае неадекватности интерфейса особенностям пользователей, эти проблемы легко решаются формализацией соответствующих требований к системе на стадии её проектирования.
Интерфейс не адекватен содержательной деятельности пользователей
Эту проблему без преувеличения можно назвать наиболее типичной для российского программного обеспечения. Суть проблемы заключается в том, что структура пользовательского интерфейса приведена в соответствие с информационными потоками (структурой объектов) внутри самой системы, а не в соответствие со структурой реальной деятельности пользователей.
Как следствие, интерфейс "зашумлен" информацией, релевантной объекту, с которым работает пользователь, но либо не нужной ему сейчас, либо не нужной ему вообще (поскольку разным сотрудникам нужна разная информация). Оборотной стороной этой проблемы является противоположная ситуация – интерфейсные элементы (выводимая информация или блоки ввода информации) являются атрибутами разных объектов, соответственно разработчики размещают их на разных экранах, игнорируя то обстоятельство, что для выполнения типовых операций с этими интерфейсными элементами пользователю необходимо взаимодействовать одновременно.
Подобного рода диалоговые окна типичны почти во всех системах
автоматизации. Наш опыт показывает, что в большей части случаев такие окна
могут быть упрощены в несколько раз.
Приведем типичный пример. При оптимизации интерфейса большой ERP системы был проведен анализ одного из диалогов запроса данных. В общей сложности, в этом окне было 15 полей ввода и 6 чекбоксов. Как показал анализ интервью пользователей, в работе постоянно нужны только два поля ввода и два чекбокса, ещё одно поле ввода нужно изредка. Таким образом, экран содержал пятнадцать ненужных элементов управления, при этом основные элементы даже не были расположены в первых рядах, на них не позиционировался курсор, они никак не были выделены. Более того, большинство пользователей не могло ответить на вопрос, что означают некоторые из имеющихся полей.
Обратной стороной этой проблемы можно считать универсальность – дешевле разработать единое окно, с которым будет работать несколько разных служащих (бухгалтер, директор, менеджер по продажам и т.п.), чем три окна для каждого из них. Но эта универсальность оборачивается значительной неэффективностью интерфейса (и, как следствие, системы в целом).
Таким образом, пользовательский интерфейс должен в первую очередь определяться структурой деятельности пользователей, а не структурой объектов, с которыми пользователь взаимодействует в процессе работы.
Интерфейс неадекватно отображает объекты системы и связи между ними
Помимо содержательной деятельности пользователей, интерфейс должен быть адекватен собственно объектам системы, что получается не всегда. Без этого интерфейс системы не будет однозначен, а неоднозначность приводит к появлению человеческих ошибок у пользователей. Большинство однозначности в интерфейсе происходит от воздействия следующих факторов:
- Взаимное размещение объектов на экране не совпадает с их логической связью и/или с их важностью. К сожалению, нормой является ситуация, при которой наиболее важные объекты (и, соответственно, наиболее важные действия) либо заслоняются от пользователя менее важными, либо находятся там, где пользователь не ожидает их найти. Например, нам известна программа, выполняющая только одну функцию, при этом вызвать эту функцию можно только из меню или с помощью пиктограммы на панели инструментов (при этом нужная пиктограмма не снабжена подписью и теряется на фоне других пиктограмм панели). Если бы кнопка для вызова этой функции была размещена ближе к центру окна программы, была сразу заметна и снабжена однозначной подписью, простота вызова функции увеличилась бы на порядок.
- В интерфейсе много избыточности. Если заранее неизвестно, как именно пользователи будут работать с системой (а это не может быть известно без тестирования прототипа интерфейса), у разработчиков возникает искушение многократно дублировать средства вызова объектов (например, вызвать один и тот же экран можно несколькими разными способами) в расчете, что если этих средств будет много, пользователь найдет хотя бы одно. Это приводит к тому, что пользователь, найдя какое-либо средство, вынужден впоследствии отфильтровывать все остальные (т.е. в интерфейсе возникает шум). В некоторых случаях возникает ещё и другая проблема: пользователь фиксируется на первом найденном объекте и игнорирует все остальные, даже если они более эффективны. Таким образом, чаще всего избыточность снижает эффективность интерфейса.
- Разные части системы разрабатываются разными разработчиками без согласования друг с другом. Эта проблема также очень остро стоит в нашей стране. Очень мало команд разработчиков обладает внутренними стандартами на интерфейс, а без таких стандартов организационно невозможно побудить разработчиков придерживаться одинаковых правил при создании интерфейса.
- Интерфейс разрабатывается без учета сложившихся стандартов (частный случай предыдущей проблемы). Эта проблема не очень остро стоит в традиционном ПО, но очень остро – в интернете, где стандартов почти нет.
Системный подход к проектированию интерфейса, а также использование стандартизованных интерфейсных библиотек (к ним относятся не только библиотеки интерфейсных элементов, но также и библиотеки терминов) вполне успешно способны решить проблемы такого плана, тем более, что эти нехитрые меры не требуют от разработчиков специальных навыков. К чести отечественных разработчиков следует отметить, что в последнее время наметилась тенденция по искоренению подобных проблем.
Выводы
Приведенная выше типология проблем, частично совпадая с другими подобными типологиями (например, из стандартов ISO), значительно от них отличается: мы не ставили перед собой задачи максимально полно охватить весь возможный круг проблем, но лишь обозначили типовые проблемы, характерные для программных продуктов, разрабатываемых в России. Таким образом, предложенная типология носит сугубо практический характер: используя её, разработчики могут получить возможность заранее диагностировать и исправлять возможные (и вероятные) проблемы при разработке пользовательского интерфейса своих систем.