Архив

Tag Archives: юзабилити

Давно наболевшая тема касательно корректного оформления документов.

Вот какой текст можно воспринять менее критично из приведенных ниже?

 

 

TEXT

 

 

 

 

 

 

 

Всем же хочется, чтобы нас окружали красивые вещи.

В том числе и красиво оформленные тексты. Я призываю — to whom it may concern — давайте оформлять документы красиво.

Вот тут пришло по рассылке anekdot.ru

«Кто не был в Европе, остерегайтесь туалетов, не по нашим мозгам они! В Штутгарте малая нужда заставила зайти вечером в уличный общественный биотуалет. Одноместная кабинка, очень аккуратная, блестящая, чистая, напичкан датчиками и управляется компьютером. Бросаешь в прорезь двери монетку 2 евро, двери автоматически открываются, зажигается свет, заходишь, двери закрываются. Клаустрофобией не страдаю, но так как всю жизнь занимаюсь электроникой и компьютерными программами, немного напрягает. Ну сделал я свои дела, нужно выходить, а кнопки для открытия двери никакой нет. Инструкций тоже. Что тупой что ли, инструкцию по пользованию сортиром тебе писать? Включаю свою логику, как немцы программу управления написали, зашёл — поднял крышку унитаза, слил воду, закрыл крышку. Может датчик какой заело? Повторяю процесс. Дверь не открывается. Может на крышку сесть надо, потом встать, потом слив воды? Повторяю процесс. Дверь не открывается. Так. Что забыл? Может руки помыть? Ещё раз повторяю процесс сначала. Подношу руку к крану, датчик срабатывает, вода течёт, потом автоматически выключается, в надежде и с грустью смотрю на дверь — не открывается. Перспектива ночевать в навороченном немецком толчке меня не вдохновила. Кричу своему товарищу, оставшемуся снаружи: «Женя, эта зараза меня не выпускает!» Он пытается дать взятку туалету, засовывая монетку в прорезь. Автомат неумолим, не берёт, и всё. На пинки и удары тоже не реагирует. Женя кричит: «Держись, сейчас полицию вызову!» От нечего делать, повторяю процесс, умываю руки, включаю фен… фен выключается, дверь открывается.

Потом где-то прочитал историю, как чувак в такой же навороченный туалет во Франции ходил. Заплатив положенные сантимы, наш соотечественник не мог и предположить, что всё внутри кабинки является стерильно чистым, а посему, как и положено чистоплотному гомосапиенсу, залез ногами на унитаз… В компьютерных мозгах туалета нестыковка: датчик пола отключен, значит, человек вышел, вода не слита, что-то не так, включил дезинфекцию. Чувак на горшке сидит, свои дела делает, а тут свет выключился, и на него душ из дезраствора как ливанёт! Он с унитаза спрыгнул, компьютер вообще заклинило: дверь закрыта, а человек появился?! И завис, предварительно включив сушку струями горячего воздуха… Несколько часов спасатели резали вандалоустойчивые двери автогеном, вытаскивая обезумевшего бедолагу из цепких лап парижского туалета. Так что я ещё легко отделался.»

 (с) Anekdot ru

 

Думаю, что Алан Купер был бы в восторге, узнав о таком чудном примере к своей «Психбольнице в руках пациентов». Ведь:

«В действительности большинство программистов неплохо справляется с проектированием, а многие из тех, кто не способен это делать, осознают свои недостатки и стараются не практиковать проектирование. Огромное «но»: когда программисты проектируют, их усилия практически всегда основываются на уникальной индивидуальности хомо логикус. Конечный результат – сложные в применении и негодные продукты, которые, как правило, нравятся только другим программистам.»

 

Если и дальше автоматизация будет проникать в нашу жизнь, то, думаю, здорово возрастет количество аварий и катастроф на «бытовом» уровне. Понятное дело, что для системы АСУ реакторной установки или истребителя степень проработки интерфейса, защиты от некорректных действий пользователя, существенно больше чем, скажем для уличного сортира. Кроме того, уровень защиты от хакерских нападок также может быть недостаточен.

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

flush-the-damn-toilet_o_1115862

На задней стороне книги приведен портрет автора, напомнивший мне по стилю стимпанк – такой высокотехнологичный гном.

При этом Джефф Раскин более чем заслуженный специалист в области пользовательских интерфейсов. Среди его детищ и Apple Macintosh и (никому правда ныне неизвестный) персональный компьютер Canon Cat, консультант множества компаний, выпускающих вычислительную и телекоммуникационную технику.

Он также придумал однокнопочную мышь для Macintosh, подход «drag and drop».

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

Могу сказать, что на страницах этой книги мне удалось найти ряд таких советов.

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

 

Итак – основные мысли и идеи, которые я выжал для себя.

Как обычно сначала нужно сказать о проблемах.

«Конечный продукт с точки зрения пользователя – это интерфейс». Чаще всего это действительно так. И интерфейсы имеют тенденцию к усложнению, часто имеют то, что Алан Купер называет «когнитивным сопротивлением».

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

По аналогии с законами робототехники Азимова предлагаются два закона проектирования интерфейсов

  1. «Компьютер не может причинить вред данным пользователя, или своим бездействием допустить, чтобы данным был причинен вред».
  2. «Компьютер не должен тратить впустую время пользователя или заставлять его выполнять действия сверх необходимого»

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

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

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

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

И разработчик должен делать интерфейс таким, чтобы локус внимания был на выполняемой задаче, а не на средствах ее выполнения. Есть ряд «фокусов» с помощью которых можно уменьшать раздражительность пользователя, если учесть что на перестройку локуса внимания может потребоваться около 10 секунд. Например, сначала показать интерфейс в общем, а потом догрузить в него недостающую информацию, дать звуковой фон.

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

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

Приведен ряд моделей для числовой оценки скорости работы с элементами интерфейса.

  • Модель GOMS, которая позволяет оценить время, которое требуется пользователю на выполнение той или иной операции при использовании интерфейса. Вводится определенная нотация, отвечающая нажатию на клавишу, указанию позиции курсором, перемещению руки с мышки на клавиатуру и т.д. С помощью такой нотации и правильно настроенных коэффициентов времени возможна довольно точная оценка, что особенно важно при сопоставлении ряда вариантов интферфейса.
  • Закон Фитса – позволяет вычислить время, необходимое для перемещения курсора и установку в определенную область экрана. Вычисления показывают, что для выбора пункта меню в стиле Apple Macintosh (привязанного в верхней грани экрана) требуется примерно в два раза времени меньше чем для выбора пункта меню в стиле Windows (расположенного под заголовком окна)
  • Закон Хика – описывает время, которое тратит пользователь на выбор их n вариантов

Выражу ряд мыслей в этаком плакатном духе

1. Диалоговым окнам нет.

Автор приводит вполне логичные доводы против применения окон типа «OK» или «YES», «NO». Первое как требующее действия с нулевой ценностью, второе как вызываеющее автоматическую реакцию без прочтения сообщения (привычки, привычки…).

2. Пользователь должен иметь возможность отменить любое свое действие.

Тогда, собственно, и отпадает в большинстве случаев надобность в диалогах подтверждения/предупреждения.

3. Должно запоминаться место в каждом документе (веб-странице), с которым пользователь работал в последний раз.

Как хорошо, что эту идею восприняли разработчики ПО для чтения электронных книжек.

4. Режимы это безусловное зло.

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

Приводится пример с режимом «LOCK» обозначенным кнопкой. Понять – что произойдет при нажатии на эту кнопку – блокировка или наоборот выход и режима блокировки далеко не так просто, даже и с помощью tool-tips.

Hint. Возможно использование квазирежимов (режим с удерживанием, например с зажатой клавишей Shift), потому что пользователь в состоянии их контролировать.

5. Пользовательские настройки это зло.

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

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

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

6. Использовать в описании элементов интерфейса сочетание «существительное-глагол», когда требуется применить некое действие к некоему объекту, что как показывают исследования позволяет увеличить скорость работы, уменьшить число ошибок.

7. Различие интерфейсов для опытных и начинающих пользователей – зло.

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

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

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

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

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

12. Ну и та мысль, которая уже несколько навязла в зубах: тщательное проектирование не замедляет, а, наоборот, ускоряет процесс разработки.

13. Советы дизайнера Edward Tufte по принципам отображения информации:

  • данные следует показать прежде всего
  • следует максимально увеличивать долю чернил (пикселов), используемых для отображения данных
  • следует максимально уменьшать долю чернил (пикселов), не используемых для отображения данных

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

  1. Например, полный отказ о файловой системы и имен отдельных файлов. Лучшее имя текстового файла, это его содержимое. Тут можно сказать, что Evernote со своим быстрым поискам по всем заметкам реализовывает такой подход, но лишь в рамках одной задачи – хранение заметок. Также Evernote реализует еще один полезный прием при поиске информации – пошаговый поиск, когда результаты поиска выводятся сразу после начала редактирования поискового фрагмента текста.
  2. Или широкое внедрение печатных команд прямо в печатаемый пользователем текст (например: Я пишу этот текст, а потом печатаю команду [send-to: me@ya.ru] и тут же инициируется почтовый клиент, который отправляет данный текст по почте).
  3. Или еще одна странная идея: в момент когда мы редактируем текст, а нам приходит письмо, то оно просто вставляется в тот текст, который мы сейчас редактируем, а далее мы решаем – как поступить со свалившимся нам текстом. Предвижу матюки, которыми будут сопровождаться подобные прерывания в работе.
  4. Ликвидация разделения рабочей среды пользователя на множество приложений, предлагающих свой контекст и каждое. Мне эта идея кажется довольно утопичной.
  5. Навигация по данным по принципу ZoomWorld, которое помогает ориентироваться в данных, за счет запоминания пространственного их размещения друг относительно друга (слева, справа, вложенные). Насколько мне известно, подобный подход не получил пока распространения, Раскин рассказывает о примере внедрения подобного интерфейса при создании информационной системы для больницы.
  6. Отказ от имен пользователей (login) и идентификация пользователя исключительно по паролю, который генерирует система для каждого пользователя.

 

 

Что мне не очень понравилось – это болезненно частое упоминание компьютера Canon Cat и клавиши LEAP на его клавиатуре. Ну, честное слово, мне это совсем не интересно. Если этот компьютер такой удобный, то почему про находки, которые были сделаны при его разработке особенно ничего не слышно сейчас?

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

 

Что приятно – можно видеть что за последние лет 5 во многих случаях разработчики следуют ряду советов и работать с программным обеспечением становится проще и безопаснее.

В дополнении с дочитываемой мною сейчас «Психбольницей в руках пациентов» Алана Купера книга помогает мне выстроить линию поведения при обсуждения основных противоречий в пользовательском интерфейсе разрабатываемых нами программ.