WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

Pages:     | 1 |   ...   | 11 | 12 || 14 | 15 |   ...   | 27 |

Ни то, ни другое не приносит удовольствия.

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

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

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

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

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

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

Почти любая навигационная система является меню. Это имеет множество Битва против меню достоинств, но и также и некоторые недостатки.

Во первых, меню ограничивает возможность выбора только определен ным набором вариантов. Это хорошо, поскольку позволяет исключить заведомо неправильные действия. Но в навигационных системах это оказывается нехорошо: взамен свободного передвижения по системе ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ВСЯЧИНА пользователям приходится ходить по заранее проделанным для них тро пинкам, т.е. степень свободы пользователей сокращается. Иногда это полезно, но чаще – нет.

Рис. 28. Примеры навигационных систем, которые принципиально действуют одинако во, но выглядят различно и выполняют разные цели. Сверху приведены четыре после довательных экрана сайта фирмы Relevare (читаются слева направо), в которых навигационная система жестко задана один раз. Снизу экран системы Antarcti.ca, позволяющей перемещаться по всем сайтам из каталога Yahoo. Единые принципы устройства навигационных систем могут быть применены многими разными путями, главное – провести анализ требований к навигационной системе и подойти к делу творчески. © Relevare, © Antarcti.ca ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ВСЯЧИНА Во вторых, любое многоуровневое меню страдает от каскадных ошибок (см. стр. 81). Способы борьбы с ними существуют, но от этих ошибок лучше бы вообще избавиться. Сделать же это можно, только изъяв либо само меню, либо потребность его использовать.

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

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

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

блок «См. также» в конце главы или раздела есть не что иное, как дополни тельная система навигации по книге.

Рис. 29. Это не выглядит как меню, это не воспринимается как меню. Тем не менее, по содержанию это обычное меню, ничем не отличающееся от меню абсолютного боль шинства сайтов. С другой стороны, такая форма представления меню позволила резко увеличить объем структуры, вмещающейся на экран, и тем самым упростить поиск нужных фрагментов системы (при этом субъективное удовлетворение здорово повышается). © Inxight Software, http://www.inxight.com При этом меню становится не основным, а дополнительным навига ционным инструментом (точнее, пассивным инструментом: на него можно смотреть, чтобы получить ответы на интересующие вопросы, но с ним не обязательно взаимодействовать).

ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ВСЯЧИНА Часть i Инвентарь В этой части описаны все кирпичи, из ко торых состоит любая программа или сайт.

Это окна, элементы управления и стандарт ные сценарии поведения системы.

ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: Элементы управления Начать разговор об элементах управления удобно с самого простого, а именно с кнопок.

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

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

Рис. 30. Всё это командные кнопки, они же кнопки прямого действия (включая гипертекстовую ссылку справа).

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

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

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

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

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

ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ЭЛЕМЕНТЫ УПРАВЛЕНИЯ Считать экранную кнопку нажатой нужно не тогда, когда пользователь нажимает кнопку мыши, а курсор находится на кнопке, а тогда, когда пользователь отпускает нажатую кнопку мыши, курсор находится на экранной кнопке и находился на ней, еще когда кнопка мыши нажималась Другой составляющей проблемы размера кнопок в интернете является несоответствие видимой площади кнопки её действующей площади. В пос леднее время, кнопки часто реализуют посредством окрашенных ячеек таблицы, в которых размещается текст кнопки, являющийся гипертексто вой ссылкой. Проблема заключается в том, что пользователи восприни мают кнопкой всю ячейку, хотя реально «нажимается» лишь малая её часть.

Рис. 31. Пример несоответствия видимой области кнопки её активной области.

В примере слева кнопка нажимаема, когда курсор находится в пределах текста, но не нажимаема, когда он находится в пределах кнопки, но не в пределах текста.

Справа правильный вариант.

Объем. Кнопка должна (или не должна) быть пользователем нажата.

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

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

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

рис. 32). В интернете обычно используют меньший набор состояний:

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

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

Вообще говоря, обычно, чем больше набор состояний, тем лучше.

Но главное не это, а отсутствие дублирования состояний, т.е. не должно быть разных состояний, выглядящих одинаково. Также очень важно делать ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ЭЛЕМЕНТЫ УПРАВЛЕНИЯ заблокированные состояния действительно заблокированными: так, на пример, в интернете очень часто встречаются кнопки, нажатие на которые открывают ту же самую страницу, т.е. нажатие которых возможно, но бес полезно. Такие кнопки должны не только выглядеть заблокированными (менее яркими и значительными, нежели обычные), но и не нести гипертекстовых ссылок.

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

Оба аргументы сильны. Действительно, стандарт. Действительно, лень.

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

Кнопканопка, запускающая действие, недаром называется командной.

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

Помимо этого, у глагольных кнопок есть одно большое достоинство.

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

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

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

С первой кнопкой понятно – это не глагол, а значит, кнопка плоха.

Кнопка одна и та же во всех диалогах, значит всё ещё хуже1.

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

1. У кнопки ОК, с другой стороны, есть два достоинства. Во первых, слишком часто оказывается, что ОК является единственным текстом, который можно уместить в кнопке (если во всех отношениях адекватный глагол слишком длинный).

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

ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ЭЛЕМЕНТЫ УПРАВЛЕНИЯ Третья, будучи и глагольной, и сравнительно уникальной, имеет другой недостаток: она почти всегда используется неправильно. На ней написано Применить, но на самом деле её значение совсем иное. Разберем это подробнее.

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

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

Pages:     | 1 |   ...   | 11 | 12 || 14 | 15 |   ...   | 27 |



© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.