Зачем лучше выравнивать метки полей?

В течение самого долгого времени я использовал выровненные по левому краю метки в своих формах, например:

Левые выровненные метки

Я сделал это, потому что думал, что ярлыки, выровненные по левому краю, облегчили читателям сканирование списка меток.

Тем не менее, я обнаружил, что моя аксиома бросила вызов недавно, наблюдая видео Billy Hollis ' поговорить из NDC 2011 , в котором Билли утверждает, что выровненные справа ярлыки просто лучше,

Ярлыки с правосторонним выравниванием

Я провел кучу исследований и нашел много дискуссий, в том числе этот вопрос UX , который сравнивает и контрастирует подходы, но ничего окончательного.

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

Я считаю, что Билли слишком умный, чтобы сделать изменения без доказательств - так что мне интересно видеть это доказательство для себя.

126 голосов | спросил Bevan 11 J000000Monday11 2011, 01:29:36

8 ответов


117

Luke Wroblewski написал об этом в ярлыках верхней, правой или левой выровненных форм (апрель 2007 г.) .

В нем он ссылается на данные по наблюдению за глазами из статьи Маттео Пензо, названной Размещение меток в формах (июль 2006 г.). Matteo сделал несколько выводов из этого исследования, в том числе, что выровненные по правому краю метки имеют более легкую когнитивную нагрузку для пользователей:

  

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

Возможно, Билли увидел статью Люка и изменил свою позицию на ее основе.

ответил Rahul 11 J000000Monday11 2011, 01:46:43
18

Выровнять по правому краю, определенно.

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

В примере, который вы показываете, я бы даже сдвинул метки немного ближе к текстовым полям, чем они есть, поскольку сами поля ближе друг к другу (опять же, неявная группировка), чем метки и поля, и мы знаем, что близость, как правило, является самой важной репликой для группировки ( Quinlan & Wilton, 1998 ). Требуется больше времени для обработки текста, чем для принятия решений о том, где фигуры («где?» Обычно получает ответ до «чего?»), Поэтому стоит сделать так же просто, как вы можете для читателя, IMO.

ответил finiteattention 11 J000000Monday11 2011, 13:17:14
10

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

В каждом случае следуют несколько рекомендаций:

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

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

ответил Steve Wortham 11 J000000Monday11 2011, 02:12:26
6

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

  1. Наилучшее выравнивание происходит вокруг центральной оси (то есть выровненных по правому краю меток и полей с левым выравниванием).

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

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

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

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

ответил Rose Matthews 12 J000000Tuesday11 2011, 15:32:25
2

Есть великое обсуждение всех сторон этого аргумента в вопросах UX.

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

ответил Scott B 18 Maypm12 2012, 20:23:10
1

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

ответил Karl Kemerait 31 Maypm12 2012, 19:53:55
1

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

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

  

Другой пример для ярлыков с надписью Top Aligned

ответил Fluke 6 Maypm14 2014, 18:58:15
0

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

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

ответил Jimmy Breck-McKye 11 J000000Monday11 2011, 22:43:28

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132