Перемещение в пределах окна

Кроме навигации меж экранами, существует к тому же навигация снутри отдельных экранов. Юзерам нужно дать возможность очень стремительно перебегать к нужным элементам управления. Для этого у их есть два метода – мышь и клавиатура. С мышью все более-менее понятно: закон оптимизация диалогового окна, уменьшающая дистанцию перемещения курсора, всегда приводит к Перемещение в пределах окна росту (хотя и маленькому) производительности юзеров.

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

Работа юзеров с кнопкой Tab может быть неприятна по двум причинам. Во-1-х, на дисплее могут быть элементы, не подразумевающие взаимодействия с юзером (к примеру, сокрытая либо заблокированная кнопка, поле вывода), но на которые перемещение совершается. Избавиться от этой задачи просто – необходимо только очевидно указать Перемещение в пределах окна, чтоб в перечень объектов, меж которыми можно передвигаться, ОС их не вносила. Во-2-х, бывают ситуации, когда зрительный порядок частей управления (происходящий из-за того, что юзеры читают экраны) не совпадает с порядком перемещения. В данном случае необходимо просто поменять у некорректных частей их место в последовательности.

Поочередные окна

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

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

Переход меж экранами.Понятно, что юзеры должны получить возможность перебегать не только Перемещение в пределах окна лишь на последующее окно в последовательности, да и на прошлые окна. Наименее естественным является другое требование к мастерам: переход должен быть очень легким. Задачка раскладывается на две составляющие: во-1-х, необходимо воплотить возможность свободного перемещения по последовательности. Если экранов мало (3-5), то полностью можно ограничиться стандартными клавишами Перемещение в пределах окна Вспять и Дальше. Если же экранов много, переход по этим кнопочкам будет, как минимум, неспешным. В таких случаях уместно дополнять кнопки раскрывающимся перечнем (при всем этом, может быть, исключая из него ещё не пройденные экраны), или, если есть место, пичкать мастера перечнем всех экранов (отмечая текущий и пройденные экраны Перемещение в пределах окна). Независимо от числа экранов в последовательности, нужно информировать юзеров об объеме оставшегося деяния (чтоб дать им возможность оценивать количество работы и тем увеличивать их чувство контроля над системой). Справедливости ради нужно уточнить, что в длинноватых последовательностях показ объема оставшихся экранов может понизить мотивацию юзеров сначала деяния, но повысить мотивацию в конце Перемещение в пределах окна («осталось незначительно, не буду это бросать»).

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

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

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

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

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


perehod-v-predlogi-drugih-chastej-rechi.html
perehodi-s-odnogo-soedineniya-tyagovih-elektrodvigatelej-na-drugoe.html
perehodim-k-veb-stilyu-zhizni.html