Обзор эргономических  проблем и недостатков
пользовательского интерфейса ПО
бухгалтерского учёта на примере 1С:Предприятие 7.5

Андрей Седельников , Центр Практичных Программ
Ярослав Перевалов , Usability в России

Автоматизация учёта -- процесс неотвратимый, и идёт полным ходом.
Но так ли идеальны и эффективны средства, которые мы используем при автоматизации?
Каковы пути их улучшения? Как установить связь между нуждами пользователя и решениями проектировщика?
Статья адресована российским разработчикам ПО.

Эргономические проблемы и недостатки

Серьёзная эргономическая экспертиза программного продукта (usability testing) -- дело нетривиальное и дорогое, проводится по специальным методикам и позволяет получить как качественные, так и количественные оценки эргономичности как программного продукта в целом, так и таких его важных компонент, как пользовательский интерфейс и пользовательская документация.

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

Такие проблемы, как правило, бывают трёх типов:
1. Глобальные эргономические противоречия
2. Неадекватное применение интерфейсной парадигмы
3. Ошибки проектирования элементов пользовательского интерфейса (как целых форм, так и аспектов применения конкретных элементов управления).

Оказывается, что практически в любом мало-мальски сложном отечественном программном продукте эргономические проблемы всех трёх типов присутствуют в изобилии.

Поскольку областей, в которых развивается отечественное софтверное производство не так уж и много (финансы, нефть-газпром, лингвистика, OCR), авторы взяли наиболее типичного представителя такого производства -- фирму 1С -- лидера в бухгалтерском ПО. Многие производители этого типа ПО идут по пятам у 1С, копируя, к сожалению, не только удачные проектные решения...
Авторы не ставили перед собой цели очернить благородный труд фирмы 1С на почве автоматизации. Продукт фирмы 1С взят лишь в качестве примера для демонстрации наиболее типичных эргономических проблемных областей в данной области производства.

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

Пользователь приобретает не готовый инструмент деятельности, а оболочку создания такого инструмента

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

Безусловно, подобное решение возникло не на пустом месте, и имеет свои причины, а именно:

• Невозможно разрабатывать программный продукт подобной направленности для каждого предприятия индивидуально. Это требует много сил и ресурсов, и стоило бы заказчику очень дорого.
• В нашей российской действительности практически на каждом предприятии, даже одного типа, -- свои особенности ведения бухгалтерского и другого учета, вызванные недостаточно строгим законодательством, различиями в знаниях и умениях конкретных бухгалтеров, не желающих изменять свой собственный подход к ведению учета при переходе к автоматизации.
• Часто меняющееся российское законодательство неминуемо влечет за собой изменение алгоритмов расчета и начисления.

Недостатки использования такого решения следующие:

• Фирма-разработчик перенесла часть своих затрат на приведение своего продукта в готовый вид на своих клиентов. Теперь они несут дополнительные, и часто значительные затраты на начальную настройку и сопровождение с помощью дополнительных людских ресурсов – “настройщиков”.
• Вследствие практически полной настраиваемости внешнего вида программы, конечный интерфейс для пользователя очень сильно зависит от тех самых “настройщиков”, которые уж точно не являются специалистами по интерфейсам. Таким образом, пользовательский интерфейс, который должен быть спроектирован специалистами, "настраивается и конфигурируется" пользователями или "настройщиками". В результате неадекватно "настроенного" интерфейса страдают как сами пользователи, так и эффективность их работы.

Вопрос этот очень спорный. Наверняка решение этой проблемы лежит где-то в области разработки более конкретных настроек 1С:Предприятие для специфических организаций ("Завод", "Школа", "Магазин", "Торговая фирма" и т.д), что сведет настройки к минимуму. Именно в этом направлении фирма 1С и работает в последнее время.

Что касается интерфейса, то здесь фирме 1С следует по крайней мере повысить его качество в своих готовых настройках, дабы конечные “настройщики” использовали его в качестве образца. Высшим пилотажем было бы задание типовых интерфейсных стилей или шаблонов.

Организация работы пользователя

Работа в современных бухгалтерских программах построена по принципу офисных пакетов: "После загрузки программы найди себе работу сам!". Так где же автоматизация?

Оказывается, в большинстве случаев программа сама может вычислить объём работ и приоритетность выполнения заданий пользователем, и предложить список работ пользователю в виде меню, списка актуальных задач (task framework), требующих пользовательского труда. Таким образом, программа должна активно помогать организовывать эффективную работу пользователя. И этот подход должен быть отражён в интерфейсных решениях. Однако, для этого необходимо не только выполнить существенный редизайн всего программного продукта, но и пересмотреть основы методологии автоматизированного учёта. Компании, которой первой удастся реализовать данный подход, обеспечено лидерство на рынке на долгие годы.

Режим же "ручного копания" (неавтоматизированного)  в документах нужно, конечно, оставить для осуществления редких и нетиповых операций, но он не обязан быть основным.

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

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

MDI

Одним из основных недоcтатков всех программ пакета является MDI (многодокументный) интерфейс. Сам по себе этот стиль интерфейса может оказаться полезным только в исключительных случаях, так как он по своей природе заставляет пользователя манипулировать окнами, вместо того, чтобы позволять ему делать свое дело. Вы сами наверняка используете большинство программ, открывая их на весь экран.

В определенный момент в истории развития интерфейсов MDI-стиль стал буквально модным, в основном из-за Windows, определившей этот стандарт. Практически каждая программа старалась использовать его, даже если в этом не было никакой необходимости. Сейчас мы наоборот наблюдаем возврат к SDI-стилю: один документ - одно окно. Microsoft тоже давно это признала, доказательством чего служит Office 2000, программы которого работают в SDI режиме.

Для программ, которые работают с разными типами документов решение этой проблемы – разработка набора так называемых рабочих областей (workspaces), то есть экранов, в каждом из которых сосредоточены необходимые функции для решения той или иной задачи пользователя (простейший пример такого приложения - Outlook Express). А для этого опять-таки необходим тщательный анализ деятельности пользователей программы, включения всего комплекса эргономических работ в процесс проектирования ПО.

Другая, и значительная, причина появления MDI-стиля в 1С – результат той особенности, о которой написано выше. Ведь если “настройщик” может изменить готовые формы документов и даже создать новые, предусмотреть для них готовые рабочие области попросту невозможно.

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

Кто нибудь проверял, работают ли пользователи c несколькими документами сразу?
Все ли открытые окна имеет смысл минимизировать (похоже, что половину открываемых окон попросту следовало бы сделать модальными, чтобы не плодить массу ненужно-открытых и забытых окон)?

Предпринимаются попытки решить эту проблему, например собственная линейка задач в последней версии 7.7, однако это всего лишь “заплатка”, которая опять же вносит путаницу для пользователя. Тем не менее организация в приложении собственной линейки задач -- хорошая идея, только её надо доработать -- помещать туда действительно задачи, а не все открытые окна (например, справочникам, открытым лишь для выбора записи, там явно не место). Скорей всего, структура бухгалтерских задач (подзадач) должна быть представлена некоторым образом, отличным от линейки задач Windows.

Оригинальные элементы управления

Во всех программах пакета встречаются элементы управления ("контролы"), специально разработанные в фирме 1С. Как и у всех элементов управления, у них есть достоинства и недостатки. Достоинства мы рассмотрим позже, а пока о недостатках.

Этот элемент управления ("грид") служит для отображения табличных данных. Главным его недостатком является то, что при перемещении ползунка полосы прокрутки выделение текущей строки тоже двигается. Такое поведение является грубым нарушением логики работы любой полосы прокрутки - прокручивать содержимое элемента управления, если оно не помещается на экране. Кроме того, если пользователь уже сделал выбор нужного ему элемента списка и либо случайно воспользовался полосой прокрутки, либо решил прокрутить список дальше и посмотреть другие строчки, его выбор просто пропадает.

По каждому столбцу такой таблицы можно производить поиск, просто набирая начальные буквы нужного слова. Однако если вводимого символа в столбце нет, программа издает противный пищащий звук, который только раздражает пользователя, но не дает никакой индикации, что произошло, и что можно делать дальше.

Если же текст, начинающийся с введенных пользователем букв найден, программа подсвечивает искомую строку и сдвигает список так, чтобы эта строка оказалась на самом верху. Во-первых, более приемлемое решение здесь - сдвигать строку в центр списка, чтобы пользователь мог просмотреть соседние позиции и вверх и вниз. А во-вторых, если список небольшой и полностью умещается в окне, то после успешного поиска, когда некоторые строки сдвигаются вверх и исчезают с экрана, у пользователя возникает впечатление, будто они были удалены. Здесь опять свою роль играет "неправильное" поведение полосы прокрутки, которая не показывает, что "вверху" есть еще записи.

Там, где подразумевается фокус на строке таблицы, в гриде неоправданно фокусируется лишь случайная ячейка (та, в которую пользователь ткнул курсором).

Неоправданной с точки зрения стремления к простоте и уменьшения "визуального шума" является и двойная разделительная линия, используемая в гриде.

Следующий комбинированный элемент управления - иерархический список:

Левая часть этого элемента управления, изображенная в виде дерева, содержит лишний корневой элемент, в данном случае это "Товары". Кроме того, это дерево не раскрыто по умолчанию при открытии окна (как показано на рисунке), и раскрывать его каждый раз приходится пользователю. Переход к нужному разделу с использованием дерева  выполняется двойным щелчком, тогда как одинарный щелчок "простаивает" - не выполняет никакой функции.

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

Но самое интересное далее. Этот элемент управления используется в основном в окнах для вывода различных справочников, которые имеют два режима вывода "обычный" и "прайс-лист" (которые практически не различаются визуально). Описанное выше поведение соответствует обычному режиму. Во втором режиме реакция элемента управления на двойной щелчок мыши полностью меняется - щелчок на группе срабатывает по всей строке, а на элементе списка вызывает закрытие окна.

Довольно сложная система, не правда ли? Может ли она вообще быть удобной для пользователя?

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

Нет единого стиля

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

Нет стандарта расположения кнопок управления окном документа - "Ok", "Закрыть", "Печать" и т.д. Поэтому пользователю приходится каждый раз их искать. И хорошо еще, если он их найдет, иногда такой кнопки может и не быть вовсе. Окно одного справочника может содержать кнопку "Закрыть", а окно другого - нет.
Заметим, что регулярное расположение кнопок (и других элементов интерфейса) оправдывает ожидания пользователя -- ему не приходится тратить усилия на поиск и распознавание кнопок. Кроме того, существуют правила оптимизации перемещений курсора мыши, которым рекомендуется следовать при размещении элементов управления пользовательского интерфейса.

Но самая интересная комбинация кнопок - это пара "Ok" и "Закрыть" (например в свойствах элемента справочника). Что делает кнопка "Закрыть"? Где же "Отменить"? Выходит, что пользователь не может отменить внесенные изменения?

Такой же беспорядок царит и в надписях полей - они располагаются от справа то слева, выглядят то подчеркнутыми, то цветными, то жирными и т.д.  Это касается как окон документов, так и отчетов для вывода на печать.

Окна сообщений

Привычка при каждой неоднозначной ситуации выводить на экран диалоговое окно, наверное, еще долго будет влиять на создание интерфейсов. Не исключение и программы 1С.   Например при закрытии окна документа пользователь может увидеть до 4-х (!) сообщений, на каждое из которых ему придется ответить.

Первое сообщение возникает при нажатии на одну из кнопок "Ok" или "Закрыть" (ранее уже было сказано о том, что кнопки "Отмена" здесь нет). Таким странным образом разработчики программы решили реализовать аварийный, редко используемый случай выхода из окна без сохранения изменений - каждый раз выдавая окно с вопросом: "Сохранить документ или нет?":

Причем одно и то же окно выдается независимо то того, на какую кнопку нажать ("Ok" или "Закрыть") - в чем тогда разница?

Следующее окно задает вопрос: "Провести документ или нет?" Опять же, в большинстве случаев ответ пользователя можно предугадать ("Да"). Зачем же тогда постоянно показывать это назойливое сообщение, тем более, что отмена проведения делается очень легко в соответствующем журнале документов.

Предыдущие два окна появляются каждый раз при закрытии окна документа.  Следующие два окна могут появиться при закрытии (а могут и не появится), однако это не уменьшает неудачность их реализации. И на этот вопрос пользователи в подавляющем большинстве случаев отвечают "Да". Последнее же окно сообщений вообще не дает никакого выбора.

Еще один пример. В программе реализована безусловно полезная возможность не удалять документы сразу, а "помечать их на удаление". Таким образом, пользователь хоть немного, но застрахован от случайного удаления. Однако показанное на рисунке окно сообщений отображается каждый раз при пометке на удаление. Это все равно как при удалении файла в Корзину Windows все равно спрашивает: "Поместить его туда или нет?"

Заметим, что существуют строго стандартизированные правила написания предупреждающих, информационных, системных сообщений, которым следует придерживаться любому производителю. Например, в заголовок окна такого сообщения принято писать о типе сообщения: "Ошибка", "Подтверждение", "Предупреждение" и т.д. Этой же цели служат и различные иконы, используемые в окнах сообщений. 
Стиль написания сообщений также должен соответствовать определённым правилам. Кнопки "Да"-"Нет" подразумевают явный вопрос и комментарий (описание) к возможным действиям пользователя. Часто возникает необходимость дополнительного действия "Отменить (операцию)", и вовсе нелишней будет в данном окне кнопка "Помощь".
Наконец, некритичную информацию принято выводить не в модальном сообщении, а в специально отведённом месте (статус-строка, различные индикаторы и журналы событий), кроме того, в надоедливые переспросы будет вежливым вставлять чекбокс типа "Не показывать больше такое сообщение". Конечно, применение того или иного приёма должно быть строго обоснованно. Одним словом -- целая наука, которая для отечественных разработчиков, к сожалению, остаётся пока тайной за семью печатями...

Отражение внутренней структуры реализации и мышления програмистов

Разработчики большинства программ с трудом могут представить себя на месте пользователей этих программ. Поэтому так часто в программах встречаются следы внутренней реализации и мышления программистов. Разработчики воспринимают их как должное, однако пользователи испытывают затруднения при работе с ними, что усложняет их работу.

Одним из ярких примеров в программах 1С является понятие "Код" в справочниках. Программисты могут понять, что это значение используется для обеспечения уникальности значений и поддержания целостности базы данных. Но зачем же осложнять этим жизнь пользователя, не только просто показывая это значение везде, но и позволяя пользователям самим манипулировать этим значением со всеми вытекающими последствиями?

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

Прочие мелкие недостатки

Наиболее часто повторяющаяся программистская ошибка -- общие кнопки (типа "ОК" - "Отменить" - "Применить") расположены внутри закладок -- нельзя так.

Генераторы документов зачастую создают гигантские по своей ширине таблицы, которые неудобно  скроллировать горизонтально, и вряд-ли они улягутся и на А3.

Нет выравнивания по десятичной точке в столбцах числовых значений (напр., при пересчёте цены без НДС).

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

Хорошие интерфейсные решения

Чтобы быть справедливым, отметим и достоинства реализации пользовательского интерфейса рассматриваемого программного продукта. Основное -- это, как ни странно, -- целостность. А именно целостность собственных элементов управления. То, что один и тот же элемент управления для работы с таблицей используется везде, где встречаются таблицы, -- это очень хорошо. Научившись работать с ним в одном месте, пользователь не будет испытывать трудностей и далее. То же самое можно сказать и про остальные элементы управления собственной разработки: иерархический список, календарь, калькулятор и т.д.

Кроме того, практически каждый из этих элементов управления имеет свои полезные особенности. Так, в иерархическом списке, при входе в глубь его, сверху отображаются вышестоящие уровни, что облегчает навигацию по списку. Иконки в журналах документов, показывающие состояние документа (проведен/непроведен) способствуют быстрому распознаванию пользователем.

Почти во всех формах присутствует контекстная справка (курсор с вопросом или кнопка "Помощь"). Это большое достижение для отечественного продукта. Однако, надо далее бороться за ясность и доступность получаемого описания контекста.

Явно присутствуют в формах кнопки создания новой записи/редактирования/удаления -- это тоже можно назвать плюсом.

Приятно радует глаз то, что настройки ширины столбцов в гридах по-умолчанию выполнены так, чтобы избежать горизонтального скроллирования, а индикатор курсора в БД (чёрный треугольничек в левой фиксированной колонке в гриде -- ненужный элемент) отсутствует.

Большинство используемых иконок осмысленны и грамотно нарисованы.

Описанные в данной статье недостатки относятся главным образом непосредственно к графическому интерфейсу программ. Исправить их сравнительно легко. Однако в том, что касается более глубокого понимания взаимодействия программы с пользователем, взгляда со стороны пользователя, а не только предметной области (бухгалтерии), программные продукты фирмы 1С все еще остаются очень далеки от совершенства.

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

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

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

Приведённые выше проблемы и недостатки присущи почти всем отечественным программным продуктам. Это есть следствие "детской болезни роста", отечественное софтверное производство тяжело избавляется от стереотипов "кустарного" производства ПО. Промышленное производство подразумевает под собой в том числе и участие специалистов по Human Factors, Usability, GUI Design в технологиях и процессах проектирования. Это приносит ощутимый эффект не только пользователям, но и производителям.

© 20 марта 2000 г.

Назад в Обзоры Программ