Должен ли текст только для чтения отображаться как обычный текст или текстовое поле только для чтения?

Должен ли я использовать метки для информации только для чтения или использовать текстовые поля только для чтения, чтобы поддерживать внешний вид полей?

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

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

mockup

скачать источник bmml - каркасы созданный с помощью макетов Balsamiq

67 голосов | спросил Homer 18 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 18 Sep 2015 16:22:56 +0300 2015, 16:22:56

12 ответов


62

Если это невозможно, покажите его как обычный текст, не текстовое поле.

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

ответил Ken Mohnkern 18 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 18 Sep 2015 16:43:05 +0300 2015, 16:43:05
27

В терминах UX необходимо учитывать копирование в буфер обмена.

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

На веб-странице

вы можете создавать и копировать данные в буфер обмена , даже если они представлены в виде текста. Нет проблем с полями Id и Stock Number здесь

введите изображение здесь »> </a> </p>

<ul>
<li>
<p> ... а как насчет раскрывающихся ящиков? </p>

<ul>
<li> Вы можете отображать их в виде текстовых полей или меток только для чтения </li>
</ul>
</li>
</ul>
<h2> В приложении </h2>

<p> то, что не находится в поле редактирования, недоступно и также выглядит некогерентным </p>

<p> <a href=введите изображение здесь »> </a> </p>

<ul>
<li>
<p> ... а как насчет раскрывающихся ящиков? </p>

<ul>
<li> Вы можете отображать их в виде текстовых полей только для чтения </li>
<li> Когда они редактируются, вы можете их изменить, поэтому <cbd> Ctrl </kbd> + <kbd> C </kbd> в сфокусированном раскрывающемся списке копирует отображаемый текст в буфер обмена </li>
</ul>
</li>
</ul></body></html>

ответил miroxlav 20 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowSun, 20 Sep 2015 15:03:26 +0300 2015, 15:03:26
25
  • Если пользователи не могут редактировать входные данные, предпочитайте использовать ярлык, чтобы избежать путаницы пользователя.

  • Если пользователи могут редактировать входные данные в некоторых случаях, предпочитайте использовать текстовые поля только для чтения.

ответил Leaf 18 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 18 Sep 2015 16:49:05 +0300 2015, 16:49:05
13

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

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

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

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

ответил xxbbcc 18 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 18 Sep 2015 22:10:59 +0300 2015, 22:10:59
6

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

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

ответил Chase Sandmann 18 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 18 Sep 2015 22:10:00 +0300 2015, 22:10:00
2

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

ответил supercat 18 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 18 Sep 2015 20:29:57 +0300 2015, 20:29:57
1

Я бы сказал, что эмпирическое правило, если в контексте:

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

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

ответил Doddy 20 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowSun, 20 Sep 2015 04:16:30 +0300 2015, 04:16:30
1

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

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

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

ответил Sebb 20 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowSun, 20 Sep 2015 06:00:55 +0300 2015, 06:00:55
1

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

Например:

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

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

ответил user52889 20 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowSun, 20 Sep 2015 21:50:01 +0300 2015, 21:50:01
0

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

ответил Eddie Hart 18 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 18 Sep 2015 22:42:03 +0300 2015, 22:42:03
0

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

ответил user70848 22 ndEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 22 Sep 2015 23:25:02 +0300 2015, 23:25:02
0

, если вы ограничены некоторой инфраструктурой , и это единственные два варианта, а затем ответы Leaf и Doddy являются лучшими решениями вашей дилеммы.

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

Editable

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

Не редактируемые

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

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

ответил Georgios Pligoropoulos 25 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 25 Sep 2015 16:38:52 +0300 2015, 16:38:52

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

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

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