Эргономика и юзабилити пользовательского интерфейса программного обеспечения (стр. 4 )

Рис. 5.2-1. Пример сокращения субъективного времени восприятия

Во время ожидания конца инсталляции пользователю показывается ряд меняющихся экранов с картинками и текстом. В данном случае выполняются две задачи: дается справка о новых возможностях продукта и сокращается субъективное время восприятия.

5.3. Приемы для уменьшения субъективного восприятия

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

Индикатор оставшегося времени. Поместите его либо в модальный диалог, либо в строку статуса. Индикатор “Система жива”. Когда оставшееся время предугадать невозможно, покажите анимированный объект, который даст пользователям понять, что система не зависла. Индикатор “Слышу и понимаю”. Когда ожидаемая задержка менее 2 секунд, показывать оставшееся время бессмысленно, поэтому просто измените форму курсора на “песочные часы”.

Для задержек от 0,1 секунды до 10 секунд:

Подтвердите щелчок мыши или нажатие клавиши в течение 0,1 секунды. Измените форму курсора на “песочные часы” или другой анимированный указатель для любой задержки более 0,5 секунды. Покажите, когда пользователь может продолжать.

Для задержек от 10 секунд до 1 минуты:

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

Для задержек от минуты до целой ночи:

Подтвердите щелчок мыши или нажатие клавиши в течение 0,1 секунды. Привлеките внимание пользователя. Индикатор, который трудно заметить, может и не существовать. Сообщите пользователю, насколько долгим будет ожидание. Если не знаете – предположите диапазон значений. Даже довольно широкого диапазона (от 3 до 15 минут) пользователю может быть достаточно для принятия решения – переключиться на другую задачу, или же пойти попить кофе. Выведите индикатор. Четко и ясно сообщите пользователю, когда он может продолжать. Это не значит, что вы должны вывести сообщение шрифтом 96 размера. Это значит, что изменения на экране должны быть значительными, для того чтобы их можно было визуально различить.

5.4. Уменьшение вероятности стрессовых ситуаций

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

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

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

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

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

5.5. Пароли

Пароли имеют три принципиальных проблемы:

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

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

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

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

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

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

5.6. Сообщение об ошибках

5.6.1. Как избежать сообщений об ошибках 5.6.2. Каким должно быть сообщение об ошибке 5.6.3. Пузырь как альтернатива сообщениям об ошибке 5.6.4. Сообщения о завершении операции

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

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

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

Рис. 5.6.4-1. Вот что бывает, если пользователь попытается ввести значение, которое ему нужно, но которое система не умеет обрабатывать. Тут возможно три альтернативных решения. Во-первых, при проектировании системы можно более тщательно подходить к выбору её функциональности. Во-вторых, можно просто игнорировать неправильность значения, округляя его до ближайшего возможного (в данном примере система так и делает, но зачем же при этом выводить сообщение!?). В-третьих, вместо обычного поля ввода можно использовать крутилку (spinner)

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

Рис. 5.6.4-2. Типичное сообщение об ошибке, вызванное нежеланием системы показать пользователю границы его действий. К тому же из сообщения не понятно в чем собственно ошибка, а междометьем «или» система расписывается в своей некомпетентности. Все усугубляется тем, что система не предоставляет ни одного варианта решения проблемы (еще бы! она ведь даже не знает точно, в чем она заключается). Даже опытный пользователь, впервые столкнувшись с этой проблемой, потратит на ее расшифровку несколько минут. Между прочим, это Office XP.

Рис. 5.6.4-3. Пример из того же Office XP, но уже на порядок лучше. Во-первых, сообщение не выглядит как банальное сообщение об ошибке, а выглядит как диалоговое окно. Во-вторых, пользователю тут же предоставляются варианты выхода из затруднительной ситуации (тут даже язык не поворачивается называть эту ситуацию проблемой). Однако есть существенный недостаток, который буквально перечеркивает все достоинства: совершенно непонятна разница между первым и последним пунктом. Ошибка в данном случае может быть фатальной. Хуже всего, что из-за несовершенства интерфейса в случае перезаписи файла не поможет даже корзина.

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

Рис. 5.6.4-4. Для кого неверное? И кто, собственно, виноват, система или пользователь?

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

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

5.7. Как избежать сообщений об ошибках

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

Еще один прекрасный способ избежать сообщений об ошибках - это сделать программу достаточно умной для того, чтобы избежать вопросов к пользователю. Многие сообщения об ошибках говорят что-то вроде "Неверные данные. Пользователь должен ввести ХХХХ". Почему же программа не может, зная, что должен ввести пользователь, ввести ХХХХ сама? Вместо запроса у пользователя имени файла на диске, давая возможность выбрать несуществующий файл, программа может запомнить, с какими файлами велась работа последний раз, и предоставить их список.

Рис. 5.7.1-1 Вот такое диалоговое окно вынуждены наблюдать пользователи, которые захотят перевести файл в PROMT’e. Банальное открытие файла разработчики превратили в увлекательную игру «Отгадай формат». Не понятно, почему программа сама не может определить, какой формат у открываемого файла. Тем более не понятно, зачем при открытии файла указывать «направление перевода», ведь это можно сделать опционально, уже непосредственно в программе. Самое интересное, что у этой истории есть продолжение.

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

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

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

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

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

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

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

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

5.7.2. Каким должно быть сообщение об ошибке

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

В чем заключается проблема? Как исправить эту проблему сейчас? Как сделать так, чтобы проблема не повторилась?

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

Итак, исходное сообщение об ошибке гласит: «Не удается сохранить файл «D:\Только для чтения. doc». Файл с этим именем уже существует и доступен только для чтения. Сохраните файл под другим именем или в другой папке». Каким образом его можно улучшить?

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

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

Таким образом, сообщение об ошибке должно стать не только сообщением – оно должно позволять разблокировать файлы, разблокировать которые возможно (т. е. записанные не на компакт-диске).

Также необходимо помнить следующие общие правила:

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

5.7.3. Пузырь как альтернатива сообщениям об ошибке

В Windows появился элемент управления, значительно лучше предназначенный для показа сообщений: пузырь (balloon).

Рис. 5.7.3-1. Пузырь, по сравнению с диалоговым окном, имеет существенные достоинства.

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

К сожалению, пузыри имеют и недостатки:

в них не может быть никаких элементов управления; пузырей пока нет в интернете.

5.7.4. Сообщения о завершении операции

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

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

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

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

Рис. 5.10-1 Пример самого бесцеремонного прерывания пользователя.

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

5.7.4.2. Используйте само-срабатывающие диалоги.

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

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

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

5.  Типичные интерфейсные ошибки отечественного ПО

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

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

Итак, проблемы, как правило, бывают трёх типов:

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

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

6.1.  Программа перегружена элементами управления

6.2.  Терминология не адекватна знаниям пользователя о системе

6.3.  От пользователя постоянно требуется дополнительная информация

6.4.  Программа не готова к немедленной работе и требуют настройки

6.5.  Программа имеет многодокументный интерфейс

6.6.  Отсутствует единый стиль

6.7.  Программа перегружена окнами сообщений

6.8.  Интерфейс отражает внутреннюю структуру реализации и мышление программистов

6.9.  Взаимное размещение объектов на экране не совпадает с их логической связью и/или с их важностью

6.10.  Пиктограммы используются некорректно

6.1. Программа перегружена элементами управления

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

Как следствие, интерфейс "зашумлен" информацией, релевантной объекту, с которым работает пользователь, но либо не нужной ему сейчас, либо не нужной ему вообще, поскольку разным сотрудникам нужна разная информация

Так при оптимизации интерфейса большой системы был проведен анализ одного из диалогов запроса данных. В общей сложности, в этом окне было 15 полей ввода и 6 чекбоксов. Как показал анализ интервью пользователей, в работе постоянно нужны только два поля ввода и два чекбокса, ещё одно поле ввода нужно изредка. Таким образом, экран содержал пятнадцать ненужных элементов управления, при этом основные элементы даже не были расположены в первых рядах, на них не позиционировался курсор, они никак не были выделены. Более того, большинство пользователей не могло ответить на вопрос, что означают некоторые из имеющихся полей.

Рис. 6.1-1. Пример перегруженного интерфейса программа для агентств недвижимости Flat.

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

Также примером перегруженного интерфейса можно назвать интерфейс 1С.Ни в одной другой программе вы не найдете такого количества интерфейсных элементов как в 1С Предприятие. Опрос пользователей этой программы выявил следующие факты:

Считают программу сложной абсолютно все.

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

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

4.3.  Многие считают что выполнили бы работу быстрее без программы.

Выводы

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

6.2. Терминология не адекватна знаниям пользователя о системе

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

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

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

Окно популярной почтовой программы Bat (рис. 6.2-1). Для того чтобы начать получать/отправлять почту пользователю необходимо пройти через обязательную процедуру определения параметров получения и отправки почты. Начинающие пользователи в массе свое прибегают в этом случае к помощи более опытных знакомых ("спецов"). Хотя процедура не казалось бы такой сложной, если бы не профессиональная терминология, использованная при обозначении параметров. Прежде всего трудности возникают с серверами. Во-первых, большинство пользователей вообще смутно представляют себе что такое сервер, не говоря уже о том что они просто не знают что такое POP и SMTP. Все было бы проще, если бы поля ввода просто обозначались бы как "Адрес". В купе с помощью размещенной на самих почтовых серверах, это помогало бы пользователю заполнять эти поля "ритуально", без построения ментальной модели. Во-вторых, параметр Connection (не говоря уже о том, что он почему-то написан по-английски), можно убрать во вкладку "Дополнительные параметры", в которую должна быть переименована вкладка "Аутентификация" (еще один не понятный термин). Туда же необходимо поместить и значения портов. Как грамотно организовать вкладку "Дополнительные параметры" это уже отдельный разговор. Тем более, можно предположить, что уже в ней будут залезать, только "продвинутые" пользователи.

Рис. 6.2-1.

В качестве примера более удобной для начинающего пользователя почтовой программы можно привести Microsoft Outlook (Рис. 6.2-2). Здесь авторы постарались более понятно изложить пользователю, что ему следует ввести в поля настройки и снабдили окно кнопкой автоматической проверки работоспособности учетной записи с введенными настройками.

Рис. 6.2-2.

Выводы

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

6.3. От пользователя постоянно требуется дополнительная информация

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

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

Рис. 6.3-1. Это сообщение возникает при удалении справочника в программе АРМ Секретарь. Мало того, что программа пугает пользователя непонятными для него терминами (база данных), она еще и спрашивает у него самого, что ей с этим делать.

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

Рис. 6.3-3. Такой тирадой сообщений засыпает пользователя программа 1С. Ни о какой комфортной работе при таком количестве сообщений не может быть и речи.

Выводы

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

6.4. Программа не готова к немедленной работе и требуют настройки

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