Компонентный подход в программировании

       

Факторы удобства использования и принципы создания удобного ПО


Основные факторы, с помощью которых можно оценить или даже измерить удобство использования программы, следующие:

  • Адекватность интерфейса.

    Адекватность пользовательского интерфейса программы — это его соответствие тем задачам, которые пользователи должны и хотели бы решать с ее помощью.

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

  • Производительность работы пользователей.

    Это количество однотипных реальных задач, которые пользователь может решить с помощью ПО за единицу времени.

  • Скорость обучения новых пользователей.

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

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

  • Эффективность предотвращения и преодоления ошибок пользователей.

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

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

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


  • Субъективное удовлетворение пользователей.

    Этот фактор наиболее тяжело проанализировать, хотя измерить его довольно просто — нужно попросить группу пользователей оценить, понравилась им система или нет, по какой-то шкале (обычно используются 5 или 7 балльные шкалы). Средний результат полученных оценок можно использовать как числовое значение этого показателя.

    Тяжелее добиться, чтобы интерфейс хорошо воспринимался пользователями в среднем — простое внесение исправлений, подсказанных одними пользователями, может отрицательно сказаться на оценках других. Считается [4], что субъективное удовлетворение пользователей почти всегда повышается в следующих случаях:

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



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

        Другой источник потери ощущения контроля — изменчивость самого интерфейса.


        Если кнопки, элементы меню и пр. то появляются в определенных местах, то исчезают или становятся неактивными по неизвестным (ненаблюдаемым непосредственно) причинам, пользователь теряется. Связанный с таким поведением системы стресс объясняется также невозможностью быстро построить в сознании модель ее поведения — система становится чем-то зыбким, неустойчивым.

      • От частых, категоричных и неинформативных сообщениях об ошибках.
    • Удовлетворение пользователей выше, если дается возможность настроить интерфейс программы так, как им нравится, но при этом предоставленных вариантов не чересчур много, чтобы пользователь не мог в них "заблудиться".


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

  • Правило доступности.

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

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

  • Правило эффективности.

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

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

  • Правило непрерывного развития.

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

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


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

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

  • Правило поддержки.

    Система должна способствовать более простому и быстрому решению задач пользователя.

    Это означает, прежде всего, что система должна действительно решать задачи пользователя. Кроме того, она должна решать их лучше, проще и быстрее, чем имевшиеся до ее появления инструменты и методы.

  • Правило соблюдения контекста.

    Система должна быть согласована с контекстом, в котором ей предстоит работать.

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

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

    Следующие принципы позволяют находить решения, повышающие удобство пользовательского интерфейса.



  • Принцип структуризации.

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

  • Принцип простоты.

    Наиболее распространенные операции должны выполняться максимально просто. При этом должны быть видимые ссылки на более сложные процедуры.

  • Принцип видимости.

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

  • Принцип обратной связи.

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

  • Принцип толерантности.

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

  • Принцип повторного использования.

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




Содержание раздела