Допустимо ли нормализовать содержимое текстового поля, когда оно теряет фокус?



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




  • пробелы в начале и конце ввода обрезаются

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


У меня есть ощущение, что это не соответствует хорошему дизайну GUI. Я прочитал Windows UX Руководящие принципы для текстовых полей , но я не сразу нашел какие-либо соответствующие правила.



Является ли нормализация содержимого текстового поля таким образом приемлемой?

559   6  

6 ответов:

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

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

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

Однако есть несколько исключений:

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

  • Разрешите другие неясности. Измените формат на однозначный, если формат пользователя открыт для интерпретации. Например, если у вас есть международные пользователи, вы можете изменить "9-8-09" на "Sep 8 2009" (или " 9 Aug 2009"), чтобы предоставить обратную связь о том, что ваше приложение считает месяц и день.

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

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

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

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

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

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

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

Я почти уверен, что видел версии Microsoft Office, которые делают это-ставят " pt.- после значения в баллах, например. Одобрение Microsoft должно быть хорошим знаком.

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

Comments

    Ничего не найдено.