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

Question

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

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

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

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

Answer 1

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

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

Answer 2

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

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

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

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

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

• Исправление орфографии, грамматики и заглавных букв. Пользователи часто ценят это, но только если есть способ переопределить это. Некоторым пользователям нравится использовать «i» как местоимение от первого лица.

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

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

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

Answer 3

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

Answer 4

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

Answer 5

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

Answer 6

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