Критерии качества интерфейса

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

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

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

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

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

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

- При каких условиях информация попадает в ДВП?

- Сколько "стоит" вспоминание?

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

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

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

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

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

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

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

На самом деле всё сложно. Разные понятия вспоминаются с разной скоростью, слова, например, вспоминаются быстрее цифр, а визуальные образы - быстрее слов. Очень сильно влияет объем выборки, т.е. вспомнить одно значение из десяти возможных получается быстрее, нежели из ста возможных. Наконец, частота вспоминания влияет на скорость вспоминания (т.е. на скорость вспоминания сильно влияет тренировка).

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

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

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

Четыре вида поиска и еще два

Существует четыре основных вида поиска информации:

- Поиск конкретных данных (сколько сделок было совершено за последние два месяца?, когда родился Пушкин?)

- Поиск расширенных данных (кто еще участвовал в этой сделке, которая принесла нам столько проблем?, какие еще произведения, помимо "Мертвые души", написал Гоголь?)

- Свободный поиск (есть ли связь между этой сделкой и какими-нибудь другими?, есть ли любовные сцены в "Кому на Руси жить хорошо"?)

- Проверка доступности (у нас есть вообще какие-нибудь данные о том, почему этот контракт был подписан?, а у меня есть какие-нибудь книги Толстого?)

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

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

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

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

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

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

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

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

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

Теперь перейдем к практике.

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

Рис. 1. Если показывать не только цифры, но и какие-либо визуальные репрезентации (слева), скорость восприятия взаимосвязи между ними многократно увеличится

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

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

Всегда выводите цифры, предназначенные для сравнения, моноширинным шрифтом.

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

Несколько иная ситуация с текстовыми данными. Понятно, что более-менее сложный связный текст автоматически визуализировать невозможно ("Мороз и солнце…"). К счастью, обычно такой необходимости и не возникает. Почти всегда нужно визуализировать сравнительные и/или описательные атрибуты, т.е. нет особой разницы между текстовыми и численными данными.

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

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

Рис. 2. Начальное состояние отчета

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

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

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

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

Пункт первый, количество оставшихся дней. В таблице из примера есть определенные проблемы - имеющаяся нотация никак не учитывает того, что измерять большие промежутки времени удобнее в неделях и месяцах. В примере же спокойно написано "142 дня". С одной стороны, это хорошо, потому что сразу видно, что времени осталось много. С другой стороны, трудно понять, сколько именно осталось времени. Т.е. лучше было бы писать либо "4 мес 22 дн", либо "4 мес 3 нед 1 дн", но, с ещё одной стороны, громоздкость таких конструкций не позволяет надеяться, что их восприятие будет легким и быстрым (не надо забывать и о существовании годов).

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

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

Рис. 3. Два варианта визуализации времени, оставшегося до протухания товара

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

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

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

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

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

Рис. 4. Индикатор оставшейся доли

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

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

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

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

Рис. 5. Промежуточное состояние отчета. Улучшен только второй столбец

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

- им нужно учиться

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

- они добавляют лишний визуальный шум

- на их рисование нужно время

- при появлении необходимости в еще одной пиктограмме возникает много проблем.

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

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

Так что идею рисования пиктограмм для этого столбца мы оставим кому-нибудь другому. Следующий столбец - "Объем". С ним c одной стороны легко, с другой - не очень. Единица измерения всего одна, что хорошо. Зато объем, занимаемый товаром, может быть большим, а значит, плохо визуализирующимся (и пятнадцать метров стеллажей говядины визуализировать нелегко, что уж говорить о ста метрах). Но это всё техника. Главное, напротив, не визуализировать параметр, а визуализировать нужную информацию из этого параметра. И с этим-то как раз не всё ясно. Что пользователь хочет узнать из чисел, показывающих, сколько места на складе занимает товар? Если ему нужно всего лишь узнать, много он занимает места или нет, лучше всего будет работать уже описанный индикатор-полоска. Если ему нужно точно узнать, сколько места занимает товар, можно оставить числа. Но вполне может оказаться и так, что ему нужно узнать, сколько процентов общей площади склада занято товаром. В этом случае подойдет либо полоска, либо более компактная круговая (блочная) диаграмма, либо те же числа. Основная проблема визуализации заключается именно в определении потребностей пользователей.

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

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

Таким образом, в результате отчет может выглядеть примерно так:

Рис. 6. Финальное состояние отчета

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

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

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

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

6. Навигация

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

Цели навигации Любая система навигации обязана выполнять несколько функций, а именно показывать пользователям:

- Где они находятся сейчас. Для понятия "не знать своё теперешнее положение" есть два коротких синонима: заблудиться и потеряться. Ни то, ни другое не приносит удовольствия.

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

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

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

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

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

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

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

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

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

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

Рис. 29. Это не выглядит как меню, это не воспринимается как меню

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

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

7. Составные части программного интерфейса

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

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

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

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

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

Добиться этого можно либо изменением состояния кнопки при наведении на неё курсором, либо установлением пустого промежутка между кнопками.

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

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

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

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

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

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

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

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

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

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

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

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

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

С первой кнопкой понятно - это не глагол, а значит, кнопка плоха. Кнопка одна и та же во всех диалогах, значит всё ещё хуже. Вторая, хоть и почти глагол, плоха, поскольку не дает контекста (к тому же отглагольные существительные воспринимаются медленнее, чем соответствующие глаголы). Главный её недостаток, впрочем, заключается в том, что её, как правило, нечем заменить, так что приходится пользоваться ею. Третья, будучи и глагольной, и сравнительно уникальной, имеет другой недостаток: она почти всегда используется неправильно. На ней написано Применить, но на самом деле её значение совсем иное. Разберем это подробнее.

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

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

Напротив, если бы вместо кнопки Применить была бы кнопка Предварительный просмотр, все бы работало великолепно. Мало того, что пользователь не путался бы в кнопках, он мог бы избежать многих ошибок, просмотрев результат своих действий перед их окончательным принятием. Но разработчикам реализовывать режим предварительного просмотра тяжело. Гораздо легче вставить кнопку Применить, а то, что пользователям это вредно, их не касается. Таким образом, кнопка Применить оказывается не просто ненужной, но и откровенно вредной. Её можно применять только в палитрах, заменяя ею кнопку ОК, чтобы показывать пользователю, что палитра не исчезнет с экрана после нажатия кнопки. Разумеется, в этом случае, с нею должна использоваться кнопка Закрыть, вместо кнопки Отмена. Во всех остальных случаях эта кнопка не нужна.

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

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

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

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

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

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

Чекбоксы и радиокнопки

Рис. 1. Пример радиокнопок и чекбоксов

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

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

В группе радиокнопок как минимум одна радиокнопка должна быть проставлена по умолчанию.

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

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

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

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

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

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

...